Re: [RFC] Embed the mesa version in the library/binary name
Hi Emil, Thanks for the heads up! Emil Velikov wrote: 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. How does this sound, do you foresee any pros/cons with the above proposal ? Any and all input is greatly appreciated, but please try to keep your replies technical and constructive. I don't believe it will change anything for DragonFly Dports, the packaging decisions are made first and foremost by the upstream FreeBSD Mesa port maintainer (Koop Mast). I believe he's on vacation right now though so you won't probably get an answer before September. As I'm not sure how many of you follow mesa-dev, would you be OK if I CC you in distro related~ish topics. Please do; even if I'm not directly concerned, I'll be happy to forward the information to the right persons. -- Francois Tigeot
Re: [RFC] Embed the mesa version in the library/binary name
On Fri, 2015-08-14 at 23:00 +0100, Emil Velikov wrote: Hmm guess I should have included this example in the original email :) $ ls -la /usr/lib/libGL*.so* libGLESv1_CM.so - libGLESv1_CM.so.11.1 libGLESv1_CM.so.1 - libGLESv1_CM.so.11.1 libGLESv1_CM.so.11.1 libGLESv2.so - libGLESv2.so.11.1 libGLESv2.so.2 - libGLESv2.so.11.1 libGLESv2.so.11.1 libGL.so - libGL.so.11.1 libGL.so.1 - libGL.so.11.1 libGL.so.11.1 abrt already looks up package versions in bug reports, so this is solving a problem I'm not having. Meh. I really, really don't like libGL.so.11 as a filename, it gives the impression that that's a real soname. libGL.so.1.11 would be better. There's at least one (incredibly boneheaded, cough, enlightenment, cough) piece of software out there that tries dlopen(libGL.so.4) etc., I'd prefer us not to contribute to that kind of misconception. - ajax
Re: [RFC] Embed the mesa version in the library/binary name
On 17 August 2015 at 09:21, Michel Dänzer mic...@daenzer.net wrote: On 15.08.2015 00:21, Emil Velikov wrote: * 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 Other suggestions and ideas are welcome but please keep the version to X.Y Do I understand correctly that your proposal is for downstream packagers to make this change? Why not upstream? Actually it's for upstream (mesa). Firstly I wanted to check if the maintainers foresee any problems with the approach before having a lovely discussion on mesa-dev :) * Why [...] - In most cases, one can easily establish if the distro provided library is overwritten. How so? Hmm indeed. Only the SONAME library is available in traces. Not sure what made me think the original library name will appear. - Allows multiple binaries to coexist, making the dynamic switching between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. Not really, since ldconfig (which needs to be run after (un)installing any shared libraries) will clobber the libGL.so.1 symlink to point to the libGL.so.X.Y with the largest X.Y. Archlinux and Gentoo install the libraries in a non ldconfig searchable location. I'd assume others do the same, so this shouldn't really be an issue ? Anyway, as Stefan mentioned there are many other problems preventing this, so this isn't really an argument against your proposal. Yes that whole thing of switching between drivers is another (nasty) topic which I'd love to discuss, but in another thread. - OpenBSD, Solaris(?) use sunos 4 style versioning - .so.major.minor FWIW, that can also be satisfied by libGL.so.1.2 . IIRC we used to ship that even on Linux, not sure when/why we switched to libGL.so.1.2.0. Maybe a side effect of adopting automake and friends. Bth I cannot find a case of 1.2 and I don't even think it's possible. The linker automatically makes a major.minor.rev library (on linux), even if rev is omitted in -version-number/version-info. Examples (taken from the upstream-tracker) mesa 3.4 - libGL.so.1.2.030400 // mesa version is stored in rev mesa 7.9 - libGL.so.1.5.070900 // something cause a minor bump ? mesa 9.0 - libGL.so.1.2.0 // automake Thanks, Emil
Re: [RFC] Embed the mesa version in the library/binary name
On 15.08.2015 00:21, Emil Velikov wrote: * 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 Other suggestions and ideas are welcome but please keep the version to X.Y Do I understand correctly that your proposal is for downstream packagers to make this change? Why not upstream? * Why [...] - In most cases, one can easily establish if the distro provided library is overwritten. How so? - Allows multiple binaries to coexist, making the dynamic switching between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. Not really, since ldconfig (which needs to be run after (un)installing any shared libraries) will clobber the libGL.so.1 symlink to point to the libGL.so.X.Y with the largest X.Y. Anyway, as Stefan mentioned there are many other problems preventing this, so this isn't really an argument against your proposal. - OpenBSD, Solaris(?) use sunos 4 style versioning - .so.major.minor FWIW, that can also be satisfied by libGL.so.1.2 . IIRC we used to ship that even on Linux, not sure when/why we switched to libGL.so.1.2.0. Maybe a side effect of adopting automake and friends. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: [RFC] Embed the mesa version in the library/binary name
Hi Emil On Fri, Aug 14, 2015 at 04:21:10PM +0100, Emil Velikov wrote: Hello all, My name is Emil and I'm the person breaking^w fixing mesa's build amongst others. 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. Thanks for informing us beforehand! * 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. +1 * 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 libGL.so.11.0 * Why A number of reasons: - Allows multiple binaries to coexist, making the dynamic switching between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. About nvidia. Benefit is small, since NVIDIA replaces half of the driver stack anyway (e.g. glx Xserver module). So you still need to make sure the right glx Xserver module is being loaded. Also the right kernel module (KMS or nvidia). And ldconfig creates the right symlink for libGL.so.1 ... How does this sound, do you foresee any pros/cons with the above proposal ? Any and all input is greatly appreciated, but please try to keep your replies technical and constructive. I don't see any regression in the change. If there are any concerns wrt the required updates (of the build/packaging recipes) I'm willing to help out. Thanks for the offer, although I don't expect any issues here. As I'm not sure how many of you follow mesa-dev, would you be OK if I CC you in distro related~ish topics. Some (not so crazy) examples: - libEGL.so has additional dependency (via libdl) of X - OpenCL only works with render node devices, kernel vY or later is required - Mesa's new library libfoo.so should be shipped with libbar.so Cc'ing me in such topics would be very much appreciated! Thanks, Stefan Public Key available -- Stefan Dirsch (Res. Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany --- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ---
Re: [RFC] Embed the mesa version in the library/binary name
On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: On Aug 14, 2015 6:21 PM, Emil Velikov emil.l.veli...@gmail.com 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/.1.2.0 as part of the linux/unix GL ABI? So not really sure that it is something we can actually change. That said, with the libOpenGL stuff we could probably do something better. BR, -R Other suggestions and ideas are welcome but please keep the version to X.Y * Why A number of reasons: - The binary driver by Nvidia has been using this approach for years. - It provides quick and easy feedback in traces - In most cases, one can easily establish if the distro provided library is overwritten. - Allows multiple binaries to coexist, making the dynamic switching between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. - OpenBSD, Solaris(?) use sunos 4 style versioning - .so.major.minor How does this sound, do you foresee any pros/cons with the above proposal ? Any and all input is greatly appreciated, but please try to keep your replies technical and constructive. I'm fully agree with proposal, but one question. How much libs/programs links against libGL or other libs? I mean how much programs we will rebuild every release? If there are any concerns wrt the required updates (of the build/packaging recipes) I'm willing to help out. As I'm not sure how many of you follow mesa-dev, would you be OK if I CC you in distro related~ish topics. Some (not so crazy) examples: - libEGL.so has additional dependency (via libdl) of X - OpenCL only works with render node devices, kernel vY or later is required - Mesa's new library libfoo.so should be shipped with libbar.so I would be happy to be CCed. Thanks Emil
Re: [RFC] Embed the mesa version in the library/binary name
On Aug 14, 2015 6:21 PM, Emil Velikov emil.l.veli...@gmail.com 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. Other suggestions and ideas are welcome but please keep the version to X.Y * Why A number of reasons: - The binary driver by Nvidia has been using this approach for years. - It provides quick and easy feedback in traces - In most cases, one can easily establish if the distro provided library is overwritten. - Allows multiple binaries to coexist, making the dynamic switching between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. - OpenBSD, Solaris(?) use sunos 4 style versioning - .so.major.minor How does this sound, do you foresee any pros/cons with the above proposal ? Any and all input is greatly appreciated, but please try to keep your replies technical and constructive. I'm fully agree with proposal, but one question. How much libs/programs links against libGL or other libs? I mean how much programs we will rebuild every release? If there are any concerns wrt the required updates (of the build/packaging recipes) I'm willing to help out. As I'm not sure how many of you follow mesa-dev, would you be OK if I CC you in distro related~ish topics. Some (not so crazy) examples: - libEGL.so has additional dependency (via libdl) of X - OpenCL only works with render node devices, kernel vY or later is required - Mesa's new library libfoo.so should be shipped with libbar.so I would be happy to be CCed. Thanks Emil
Re: [RFC] Embed the mesa version in the library/binary name
On 14 August 2015 at 18:52, Igor Gnatenko ignatenkobr...@fedoraproject.org wrote: I'm fully agree with proposal, but one question. How much libs/programs links against libGL or other libs? I mean how much programs we will rebuild every release? The libGL.so and libGL.so.1 (and equivalents for other libraries) will not be renamed. Thus nothing will need to be rebuild, as everything is (and will be) using the original libGL.so.1 soname. Hmm guess I should have included this example in the original email :) $ ls -la /usr/lib/libGL*.so* libGLESv1_CM.so - libGLESv1_CM.so.11.1 libGLESv1_CM.so.1 - libGLESv1_CM.so.11.1 libGLESv1_CM.so.11.1 libGLESv2.so - libGLESv2.so.11.1 libGLESv2.so.2 - libGLESv2.so.11.1 libGLESv2.so.11.1 libGL.so - libGL.so.11.1 libGL.so.1 - libGL.so.11.1 libGL.so.11.1 I would be happy to be CCed. Great, thanks. -Emil
Re: [RFC] Embed the mesa version in the library/binary name
On Aug 14 2015 or thereabouts, Emil Velikov wrote: On 14 August 2015 at 20:47, Rob Clark rcl...@redhat.com wrote: On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: On Aug 14, 2015 6:21 PM, Emil Velikov emil.l.veli...@gmail.com 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
Re: [RFC] Embed the mesa version in the library/binary name
On 14 August 2015 at 20:47, Rob Clark rcl...@redhat.com wrote: On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: On Aug 14, 2015 6:21 PM, Emil Velikov emil.l.veli...@gmail.com 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. That said, with the libOpenGL stuff we could probably do something better. That does not prevent us from doing minor tweaks :) Cheers, Emil
