From owner-freebsd-x11@freebsd.org Fri Aug 14 23:37:32 2015 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1716F9BA992 for ; Fri, 14 Aug 2015 23:37:32 +0000 (UTC) (envelope-from rclark@redhat.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EA6BE1893 for ; Fri, 14 Aug 2015 23:37:31 +0000 (UTC) (envelope-from rclark@redhat.com) Received: by mailman.ysv.freebsd.org (Postfix) id E707B9BA991; Fri, 14 Aug 2015 23:37:31 +0000 (UTC) Delivered-To: x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCB2E9BA990 for ; Fri, 14 Aug 2015 23:37:31 +0000 (UTC) (envelope-from rclark@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADFDB1892 for ; Fri, 14 Aug 2015 23:37:31 +0000 (UTC) (envelope-from rclark@redhat.com) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 603758E766; Fri, 14 Aug 2015 23:37:30 +0000 (UTC) Received: from mail.corp.redhat.com (vpn-61-243.rdu2.redhat.com [10.10.61.243]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7ENbQiV019084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Aug 2015 19:37:28 -0400 Date: Fri, 14 Aug 2015 19:37:26 -0400 From: Rob Clark To: Emil Velikov Cc: Igor Gnatenko , riastradh@netbsd.org, Stefan Dirsch , Andreas Radke , Jan de Groot , Jonathan Gray , =?utf-8?B?RnJhbsOnb2lz?= Tigeot , Matthew Green , =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= , mesa@packages.debian.org, x11@freebsd.org, mesa-owner , Adam Jackson Subject: Re: [RFC] Embed the mesa version in the library/binary name Message-ID: <20150814233726.GD19762@mail.corp.redhat.com> References: <20150814194753.GC19762@mail.corp.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Mailman-Approved-At: Sat, 15 Aug 2015 01:01:55 +0000 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 23:37:32 -0000 On Aug 14 2015 or thereabouts, Emil Velikov wrote: > On 14 August 2015 at 20:47, Rob Clark wrote: > > On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: > >> On Aug 14, 2015 6:21 PM, "Emil Velikov" wrote: > >> > > >> > Hello all, > >> Hi, > >> > > >> > My name is Emil and I'm the person breaking^w fixing mesa's build > >> > amongst others. > >> Yes, we know :D > >> > > >> > A while back I had this idea of renaming the libraries provided by > >> > mesa to include the actual version number. Prior to doing anything > >> > "crazy" I've decided to seek your feedback. > >> > > >> > > >> > * What > >> > The idea is to rename (ideally) all of the versioned libraries. > >> > Unversioned ones such as radeonsi_dri.so will remain as is. > >> > > >> > Note: the soname and symlinks will stay to avoid breaking compatibility. > >> > > >> > > >> > * How > >> > While I haven't fully decided on the exact approach I'm thinking of > >> > something like: > >> > libGL.so.1.0.0 -> libGL.so.11.0 or libGL.so.110.1 or libGL.so.11.01 > >> I'd like to see 11.0 for 11.0, 11.1 for 11.1 and etc. > > > > Adam probably knows better, but I thought libGL.so/.1/ > These files are symlinks to the actual library and will not be renamed. > > >.1.2.0 as part of > > the linux/unix GL ABI? So not really sure that it is something we can > > actually change. > > > I'm fairly confident it's not part of the ABI. I've been through the > documentation five+ times, solely looking for it and did not see any > hints, let alone explicit statement. Not to mention that nvidia has > been using this approach since dawn of time. Even their oldest legacy > driver 71.x (one supporting Geforce 256) uses it. Ok, if it is just a matter of adding symlinks, and apps can still link against libGL.so or libGL.so.1 or whatever, it seems fine. And I guess if nv is doing it, then it is probably not non-compliant. Anyways, I'm defn not the expert in such things, but I think there is some expectation that apps can link against a driver agnostic shared lib path an expect things to work with other drivers.. (ofc having an icd seems like it would be a good thing, so hopefully libOpenGL actually happens some day) BR, -R > > > That said, with the libOpenGL stuff we could probably do something > > better. > > > That does not prevent us from doing minor tweaks :) > > Cheers, > Emil