Re: libtool issue with latest Sun cc compiler on Linux

[Terry D. Dontje]

Very interesting, I think it is coming from ld look at the following:

address@hidden:~/tmp/compissue> cc -G -Wl,--whole-archive,libtest.a 
-Wl,--no-whole-archive -Wl,-soname -Wl,libtest.so.0 -o libtest.so.0.0 
/dev/null -#
### Note: NLSPATH = 
/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
###     command line files and options (expanded):
### -Wl,--whole-archive,libtest.a -Wl,--no-whole-archive -Wl,-soname 
-Wl,libtest.so.0 -xarch=generic64 -shared /dev/null -o libtest.so.0.0
### Note: LD_LIBRARY_PATH = 
/opt/sge/lib/lx24-amd64:/sw/sles9-x64/gt-4.0.3/lib
### Note: LD_LIBRARY_PATH_64 = <null>
### Note: LD_RUN_PATH = <null>
/usr/bin/ld --whole-archive libtest.a --no-whole-archive -soname 
libtest.so.0 --eh-frame-hdr -m elf_x86_64 -dynamic-linker 
/lib64/ld-linux-x86-64.so.2 
/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/lib/amd64/crti.o 
/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/lib/amd64/values-xa.o 
-o libtest.so.0.0 -shared /dev/null -Y 
"/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/lib/amd64:/lib/amd64:/usr/lib/amd64" 
-Qy -lc 
/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/lib/amd64/libc_supp.a 
/opt/zmaw/sw/sles9-x64/SUN/SunStudioExpress-linux-2006-12/sunstudiomars/prod/lib/amd64/crtn.o
/dev/null: file not recognized: File truncated
address@hidden:~/tmp/compissue>

The version is definitely different than yours:

address@hidden:~/tmp/compissue> ld --version
GNU ld version 2.16.91.0.7-amd-sles9 20060317
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

--td
Ralf Wildenhues wrote:

> Hello Terry,
>
> Thanks for the report.
>
> * Terry D. Dontje wrote on Fri, Feb 16, 2007 at 01:55:10PM CET:
>  
>
> > address@hidden:~/tmp/compissue>  cc -mt -c foo.c  -KPIC -DPIC -o foo.o 
> > address@hidden:~/tmp/compissue> ar cru libtest.a foo.o 
> > address@hidden:~/tmp/compissue> cc -G -Wl,--whole-archive,libtest.a 
> > -Wl,--no-whole-archive -lnsl -lutil -lm -lc -mt -Wl,-soname 
> > -Wl,libtest.so.0 -o libtest.so.0.0 /dev/null
> > /dev/null: file not recognized: File truncated
> >    
>
> That's weird.  I've had a chance to test this out now, and surprisingly,
> I cannot reproduce this error over here with either of these versions:
>
> | cc: Sun C 5.9 Build18_0 2006/03/13
>
> | cc: Sun C 5.9 Linux_i386 Build35_2 2006/12/04
>
> This is both on x86, and adding the /dev/null works:
>
> $ touch a.c; cc -c a.c; ar cru liba.a a.o
> | "a.c", line 1: warning: empty translation unit
> $ cc -G -Wl,--whole-archive,liba.a -Wl,--no-whole-archive -Wl,-soname 
> -Wl,libtest.so.0 -o libtest.so.0.0 /dev/null -#
> | ### Note: NLSPATH = 
> /opt/sunstudiomars/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/sunstudiomars/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
> | ###     command line files and options (expanded):
> | ### -Wl,--whole-archive,liba.a -Wl,--no-whole-archive -Wl,-soname 
> -Wl,libtest.so.0 -shared /dev/null -o libtest.so.0.0
> | ### Note: LD_LIBRARY_PATH = /opt/intel_cc_80/lib:/opt/intel_fc_80/lib
> | ### Note: LD_RUN_PATH = <null>
> | /usr/bin/ld --whole-archive liba.a --no-whole-archive -soname libtest.so.0 -m elf_i386 
> -dynamic-linker /lib/ld-linux.so.2 /opt/sunstudiomars/prod/lib/crti.o 
> /opt/sunstudiomars/prod/lib/values-xa.o -o libtest.so.0.0 -shared /dev/null -Y 
> "/opt/sunstudiomars/prod/lib:/lib:/usr/lib" -Qy -lc 
> /opt/sunstudiomars/prod/lib/libc_supp.a /opt/sunstudiomars/prod/lib/crtn.o
> $ echo $?
> 0
> $ /usr/bin/ld --version
> | GNU ld version 2.17 Debian GNU/Linux
>
>  
>
> > Note the following is my Sun CC version info:
> > cc: Sun C 5.9 Linux_i386 Build35_2 2006/12/04
> >    
>
> Weird, that's the same version.  So how can I reproduce this failure, so
> that we don't fall into this trap again?  Is the error even produced by
> cc, or by chance by ld?
>
> Thanks,
> Ralf
>