Front page | perl.perl5.porters |
Postings from June 2004
# New Ticket Created by Nicholas Gianniotis
# Please include the string: [perl #30450]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=30450 >
Hi,
When I built perl 5.6.1 on my Solaris 8 (x86) system several years
ago, configure did not correctly detect that GNU gcc was invoking the
Solaris ld(1) in /usr/ccs/bin/ld. As a result, it (incorrectly)
assumed GNU ld(1) was being used, and configured ld options that were
incompatible with Solaris ld (-Wl,-E). This caused the link phase to
fail.
Tonight I just tried to build perl 5.8.4 and found the same situation
still persists in the new version of hints/solaris_2.sh, causing the
same failure. I hope that by contributing the fix below, this can be
incorporated into future releases to solve this problem.
When investigating the problem, I discovered that when gcc is invoked
on the test file "try.c", the output was:
% gcc -v -o /tmp/try /tmp/try.c
Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)
/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dunix -D__svr4__ -D__SVR4 -Dsun -D__unix__ -D__svr4__ -D__SVR4 -D__sun__ -D__unix -D__sun -Asystem(svr4) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /tmp/try.c /tmp/ccrBGHzD.i
GNU CPP version 2.95.3 20010315 (release) (i386 System V Release 4)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/../../../../i386-pc-solaris2.8/include
/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/../../../../include/g++-3
End of omitted list.
/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/cc1 /tmp/ccrBGHzD.i -quiet -dumpbase try.c -version -o /tmp/cc45Owx7.s
GNU C version 2.95.3 20010315 (release) (i386-pc-solaris2.8) compiled by GNU C version 2.95.3 20010315 (release).
/usr/ccs/bin/as -V -Qy -s -o /tmp/cchhqCXB.o /tmp/cc45Owx7.s
as: Sun WorkShop 6 99/08/16
/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o /tmp/try /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/crt1.o /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/crtbegin.o -L/usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib /tmp/cchhqCXB.o -lgcc -lc -lgcc /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/crtend.o /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/crtn.o
ld: Solaris Link Editors: 5.8-1.272
Notice how gcc emits a trace line for the invocation of as(1)
("/usr/ccs/bin/as ..."), but it does NOT emit a similar line when it
invokes ld(1). Therefore, the test in solaris_2.sh (line 239) which
looks for the string "/usr/ccs/bin/ld" fails. I have added 3 lines to
perform an additonal test to search for the string "ld: Solaris Link
Editors", which correctly detects use of Solaris ld(1) in this
situation:
if echo "$verbose" | grep ' /usr/ccs/bin/ld ' >/dev/null 2>&1; then
# Ok, gcc directly calls the Solaris /usr/ccs/bin/ld.
:
+ elif echo "$verbose" | grep "ld: Solaris Link Editors" >/dev/null 2>&1; then
+ # same as above, but newer gcc does not echo the path "/usr/ccs/bin/ld" when it invokes ld... that's why the original test above fails
+ :
elif echo "$verbose" | grep "ld: Software Generation Utilities" >/dev/null 2>&1; then
# Hmm. gcc doesn't call /usr/ccs/bin/ld directly, but it
# does appear to be using it eventually. egcs-1.0.3's ld
# wrapper does this.
# All Solaris versions of ld I've seen contain the magic
# string used in the grep.
:
Hope this fix helps. Don't hesitate to write if you need further
details.
Best regards,
Nick Gianniotis
Thread Next