|
From: | Terry D. Dontje |
Subject: | Re: libtool issue with latest Sun cc compiler on Linux |
Date: | Fri, 16 Feb 2007 14:45:09 -0500 |
User-agent: | Mozilla Thunderbird 1.0.7 (X11/20050930) |
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 truncatedThat'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/LinuxNote the following is my Sun CC version info: cc: Sun C 5.9 Linux_i386 Build35_2 2006/12/04Weird, 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
[Prev in Thread] | Current Thread | [Next in Thread] |