GCC 3.2.2

torsten torsten at inetw.net
Thu Feb 6 19:07:01 PST 2003


On Thu the 06 Feb 2003 at 20 hours EST
K wrote...
>On Thursday 06 February 2003 06:07 pm, torsten wrote:
>> libstdc++ is the problem.  Mozilla binary is compiled againt
>> it dynamically,
>> obviously not the version with my compiler.  I just create a
>> symlink, and
>> mozilla seems to be happy.
>>
>> This may be a "purity" issue - having binaries linked to old
>> libraries does
>> not sit well with me.
>
>It should work if the source code is maintained properly.  The 
>way it's supposed to work is this:
>
>Every dynamic library exports a certain ABI.  Every dynamic 
>library also embeds a SONAME tag; when ld links a binary with a 
>dynamic library like libpng.so, it will link the binary to the 
>name in libpng's SONAME field (libpng.so.3) rather than the 
>actual filename (libpng.so).

I've always wondered about this naming convention.  
Mozilla-1.3a links against    
libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x402d1000)

which I've linked against (and this works)
libstdc++-libc6.1-1.so.2 ->
/usr/src/gcc-2.95.3/usr/lib/libstdc++-libc6.2-2.so.3

so these are theoretically binary incompatible per SONAME?
--

Also, gcc-3.2 provides
libstdc++.so.5.0.0 and libstdc++.so.5.0.0

and linking these so mozilla loads them:
 relocation error: /usr/local/mozilla/libgkgfx.so: undefined symbol:
__builtin_vec_new

So, I guess the ABI was broken between gcc-2X and gcc-3X.   :)

Fascinating! Thanks!
Torsten
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list