[RFC] Embed the mesa version in the library/binary name

Emil Velikov emil.l.velikov at gmail.com
Mon Aug 17 13:37:13 UTC 2015


On 17 August 2015 at 09:21, Michel Dänzer <michel at 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


More information about the freebsd-x11 mailing list