DragonFly bugs List (threaded) for 2004-07
Re: Unusual error message from gcc34 ?
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1089243450 crater_reader.dragonflybsd.org 50171 18.104.22.168
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:1596
Jeroen Ruigrok/asmodai wrote:
> This numbering is malpractice within the ELF world, since ELF ignores any
> minor numbers anyway. Blame the Linux world for corrupting the use of ELF
> shared libraries with additional (aout-style) version numbers and using
> symlink hell to point files to the 'right' version.
It's worse, sadly. If this were the only problem, it'd be easy to
resolve. Unfortunately, GNU binutils and gcc like to add their own
(proprietary) versioning information within the object itself.
My version of libc.so on Linux, for example, knows that it's
glibc-2.3.2, compiled with gcc-3.2.3. If a program was compiled with
gcc-3.3 and/or against glibc-2.4, ld.so is unwilling to launch it with
my glibc. <sigh>
Anyway... this makes me long for BSD at work.
Even the standardized ELF method of versioning has the potential to
wreak havoc (though I haven't encountered this). Tcl uses a similar
style of versioning; for example, if I say that I want version 3.2 of a
package, it'll allow any 3.x (x>=2) version of the package to be used,
but not 4.x. At some point, the [incr Widgets] did a marketing-style
versioning move and changed their version number from 3.2 to 4.0 --
which broke every application which used it. Oops.