bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Inconsisten -export-symbols-regex behaviour in libtool 1.4.*


From: Juergen Keil
Subject: Inconsisten -export-symbols-regex behaviour in libtool 1.4.*
Date: Wed, 15 Jan 2003 14:09:48 +0100 (MET)

Hi,

I'm seeing inconsistent behaviour for libtool's -export-symbols-regex option,
on:

- Platform 1: solaris 9, GCC 2.95.3, /usr/ccs/bin/ls
- Platform 2: linux 2.4.20, GCC 3.2, GNU ld version 2.13.90.0.4

when building shared libraries.

On solaris using the system linker, -export-symbols-regex removes unwanted
symbols from the "dynamic symbol table",  but on linux the unwanted
symbols are removed from the ordinary "symbol table".

Since libtool was invented to simplify creating dynamically linked shared
object files in the first place,  I think libtool's behaviour on solaris
makes sense and allows to control what symbols are usable from a shared
library.  The linux behaviour seems broken to me.


To reproduce the issue:

% cat x.c
int
foo()
{
    return 0;
}

int
bar()
{
    return foo();
}
% libtool --mode=compile gcc -c x.c
% libtool --mode=link gcc -o libx.la x.lo -rpath /tmp -export-symbols-regex bar


On Solaris, I get the following "dynamic symbol table":

solaris% nm -Dp .libs/libx.so


.libs/libx.so:
0000066124 D _DYNAMIC
0000066236 D _edata
0000066236 B _end
0000000573 D _etext
0000066112 D _GLOBAL_OFFSET_TABLE_
0000000000 D _PROCEDURE_LINKAGE_TABLE_
0000000536 T bar                       <<<< only "bar" is exported on solaris,
                                            as expected

On Linux, I get the following "dynamic symbol table":

linux% nm -Dp .libs/libx.so
00001748 A _DYNAMIC
0000055c T _init
00001848 A __bss_start
00000720 T _fini
         w __cxa_finalize
000006b4 T foo                         <<<< "foo" is exported, on linux?!
00001848 A _edata
00001824 A _GLOBAL_OFFSET_TABLE_
0000184c A _end
000006be T bar
         w _Jv_RegisterClasses
         w __gmon_start__


Note that for the ordinary symbol table, the situation is exactly reversed:

solaris% nm -p .libs/libx.so


.libs/libx.so:
0000000000 s 
0000000000 s 
0000000000 s 
0000000000 s 
0000066236 b 
0000066236 s 
0000066124 s 
0000066112 s 
0000000524 s 
0000000508 s 
0000000480 s 
0000000376 s 
0000000248 s 
0000000180 s 
0000000000 s 
0000000000 f .libs/libx.so.0.0.0
0000066124 D _DYNAMIC
0000066236 D _edata
0000066236 B _end
0000066236 b _END_
0000000573 D _etext
0000066112 D _GLOBAL_OFFSET_TABLE_
0000000000 D _PROCEDURE_LINKAGE_TABLE_
0000000000 d _START_
0000000536 T bar
0000000524 t foo
0000000524 n gcc2_compiled.
0000000000 f x.c


linux% nm -p .libs/libx.so
000006be T bar


                          ----------------------------------
                          
Shouldn't libtool use GNU ld's --version-script option, with a version script
like this, generated on the fly:

   EXPORTED {
   global:
        bar;
   local: *;
    };

??





reply via email to

[Prev in Thread] Current Thread [Next in Thread]