Re: Unusual error message from gcc34 ?

[David Cuthbert <dacut@xxxxxxxxx>]

74$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20040707064920.GH1768@xxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <20040707064920.GH1768@xxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 24
Message-ID: <40ec893a$0$50171$415eb37d@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.