libtool
[Top][All Lists]
Advanced

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

cross-platform bug: static archives have duplicate .o's


From: Charles Wilson
Subject: cross-platform bug: static archives have duplicate .o's
Date: Sat, 06 Jul 2002 19:44:00 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

I previously reported this for the cygwin platform -- but it appears to be a general bug, since I obseved it also on linux. (libtool-CVS, 20020705).

I've attached a small example (from my dllhelpers kit, but it works without changes on linux, as well -- ah, the joys of the autotools...) Just unpack, run bootstrap, configure, make.

What happens is that the static archive includes both the "-PIC" objects AND the non-PIC objects. In the past, this caused cygwin's "strip" to go berzerk -- but at least THAT has been fixed (cygwin's strip can now deal with duplicate .o's)

However, this just CAN'T be good, can it?

    I think the problem in libtool is here: line 4296 in
  ltmain.in:
    oldobjs="$oldobjs$old_deplibs $non_pic_objects"
  well, $non_pic_objects=a.o, but $oldobjs=.libs/a.o
  so both object files get ar'ed into the static lib.  I'm not sure
  what the problem is: should we prevent .libs/a.o (the PIC object)
  from getting added to $oldobjs, or should this line actually read:
    oldobjs="$non_pic_objects"
  and nothing else?

--Chuck

(From LINUX):
...
/bin/sh ./libtool --mode=link gcc -g -O2 -o libcdll.la -rpath /usr/local/lib -version-info 1:0:1
-no-undefined cdll.lo
gcc -shared .libs/cdll.o -Wl,-soname -Wl,libcdll.so.0 -o .libs/libcdll.so.0.1.0
(cd .libs && rm -f libcdll.so.0 && ln -s libcdll.so.0.1.0 libcdll.so.0)
(cd .libs && rm -f libcdll.so && ln -s libcdll.so.0.1.0 libcdll.so)
ar cru .libs/libcdll.a  .libs/cdll.o   cdll.o
ranlib .libs/libcdll.a
creating libcdll.la
...

(From CYGWIN):
...
/bin/bash ./libtool --mode=link gcc -g -O2 -o libcdll.la -rpath /usr/local/lib -version-info 1:0:1 -no-undefined cdll.lo gcc -shared .libs/cdll.o -o .libs/cygcdll-0.dll -Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/libcdll.dll.a
Creating library file: .libs/libcdll.dll.a
ar cru .libs/libcdll.a  .libs/cdll.o   cdll.o
ranlib .libs/libcdll.a
creating libcdll.la
...

Notice that in each case, the ar command includes both cdll.o AND .libs/cdll.o. This is bad...

On linux, here's what nm reports:

------------ begin ------------------

cdll.o:
00000000 t
00000000 d
00000000 b
00000000 ?
00000000 ?
00000000 ?
00000000 ?
         U _GLOBAL_OFFSET_TABLE_
00000000 a cdll.c
00000010 T dll_double_square
00000020 T dll_float_square
00000050 T dll_get_global_int_var
00000000 D dll_global_int_var
00000000 T dll_int_square
00000030 T dll_set_global_int_var

cdll.o:
00000000 t
00000000 d
00000000 b
00000000 ?
00000000 ?
00000000 ?
00000000 ?
00000000 a cdll.c
00000010 T dll_double_square
00000020 T dll_float_square
00000040 T dll_get_global_int_var
00000000 D dll_global_int_var
00000000 T dll_int_square
00000030 T dll_set_global_int_var

------------ end ------------------

And on cygwin:

------------ begin ------------------

cdll.o:
00000000 b .bss
00000000 d .data
00000000 N .stab
00000000 N .stabstr
00000000 t .text
00000000 t ___gnu_compiled_c
00000010 T _dll_double_square
0000001c T _dll_float_square
00000038 T _dll_get_global_int_var
00000000 D _dll_global_int_var
00000000 T _dll_int_square
00000028 T _dll_set_global_int_var
00000000 ? cdll.c
00000000 t gcc2_compiled.

cdll.o:
00000000 b .bss
00000000 d .data
00000000 N .stab
00000000 N .stabstr
00000000 t .text
00000000 t ___gnu_compiled_c
00000010 T _dll_double_square
0000001c T _dll_float_square
00000038 T _dll_get_global_int_var
00000000 D _dll_global_int_var
00000000 T _dll_int_square
00000028 T _dll_set_global_int_var
00000000 ? cdll.c
00000000 t gcc2_compiled.

------------ end ------------------



Attachment: libtool_demo.tar.bz2
Description: Binary data


reply via email to

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