Unusual error message from gcc34 ?
David Cuthbert
dacut at kanga.org
Wed Jul 7 16:39:10 PDT 2004
74$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20040707064920.GH1768 at xxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <20040707064920.GH1768 at xxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 24
Message-ID: <40ec893a$0$50171$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 209.195.151.220
X-Trace: 1089243450 crater_reader.dragonflybsd.org 50171 209.195.151.220
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.
More information about the Bugs
mailing list