GNOME Bugzilla – Bug 456383
Symbol versioning
Last modified: 2011-10-25 02:02:49 UTC
Hi, This is to propose symbol versioning for glib. Linker scripts permitting symbol versionning have been supported for a long time and are a feature in both GNU and Sun linkers. This is the ld documentation on symbol versioning: http://sourceware.org/binutils/docs-2.17/ld/VERSION.html My understanding of the added benefits are that these can make for faster runtime linker load times and may help avoiding nasty bugs when mixing multiple versions of the same library at runtime. This was also requested in Debian bug http://bugs.debian.org/264400. Bye,
Wouldn't this break ABI when versioning all symbols now? If this is the case this is probably more a bug for glib 3.0 :) Apart from that, this IMHO definitely makes sense.
> My understanding of the added benefits are that these can make for faster > runtime linker load times and may help avoiding nasty bugs when mixing multiple > versions of the same library at runtime. If this is the motivation, I'm definitively against it
I don't see any immediate advantages either, just maintenance pain.
(In reply to comment #2) > > My understanding of the added benefits are that these can make for faster > > runtime linker load times and may help avoiding nasty bugs when mixing multiple > > versions of the same library at runtime. > If this is the motivation, I'm definitively against it Could you please explain why you're against avoiding nasty crashes? Another motivation we have is that it makes it simpler to know against which glib versions a binary can run; for example you can build a package against whatever version of glib is in the development archive and move it to a different archive when it's tested if it doesn't need symbols added in the version of glib of the development archive but only uses symbols from the older version of glib. The current status is that all packages built against a version of glib must wait for this version of glib to be allowed in before these packages are allowed. (In reply to comment #3) > I don't see any immediate advantages either, just maintenance pain. Could you please explain why avoiding nasty crashes isn't an immediate advantage? In the case of the Debian bug quoted, timidity indirectly pulls glib 1.2 and 2.0, and crashes as a result. Not only would we avoid crashes in such combinations of libraries, it might also be a good idea in preparation of version 3 of glib.
> In the case of the Debian bug quoted, timidity indirectly pulls glib 1.2 and > 2.0, and crashes as a result. Not only would we avoid crashes in such > combinations of libraries, it might also be a good idea in preparation of > version 3 of glib. It would be much better to fix any broken applications like this by dropping the glib 1.2 dependency. glib 2.0 has only out how long now, 6 years ?
(In reply to comment #5) > It would be much better to fix any broken applications like this by dropping > the glib 1.2 dependency. glib 2.0 has only out how long now, 6 years ? These are the applications which were not fixed after 6 years, imagine how many crashes were caused by this situation in the first years (and have probably been hard to diagnose), and imagine the time it will take to migrate to an hypothetical glib 3 and for how long we will get subtle crashes! Plus fixing it in glib is centralized and has other benefits while fixing all applications might simply be impossible: what about binary modules which still need to be supported in applications which get ported to newer versions? The example bug is quite interesting in that it doesn't even crashes because of the direct libraries it uses, but because of indirect dependencies (via gtk 1.2 and arts).