Front page | perl.perl5.porters |
Postings from November 2003
Re: [perl #24439] 64 bit build failure on Solaris 9
Thread Previous
|
Thread Next
From:
Andy Dougherty
Date:
November 20, 2003 06:37
Subject:
Re: [perl #24439] 64 bit build failure on Solaris 9
Message ID:
Pine.SOL.4.53.0311200926550.25274@maxwell.phys.lafayette.edu
On Mon, 10 Nov 2003, Alan Burlison wrote:
> Berger, Daniel (via RT) wrote:
>
> > ld: fatal: file miniperlmain.o: wrong ELF class: ELFCLASS64
> > ld: fatal: File processing errors. No output written to miniperl
> > collect2: ld returned 1 exit status
> > *** Error code 1
> > make: Fatal error: Command failed for target `miniperl'
>
> I don't use gcc, but from looking at the gcc flags and the linker error
> mrssage it appears that you are building libperl as LP64 (64-bit) but
> building miniperlmain as LP32 (32 bit).
Yes, I think that's almost it. Looking closely at the command line
issued
gcc -o miniperl miniperlmain.o opmini.o libperl.a [ . . .]
miniperlmain.o is the first object file mentioned. By the time ld
gets to it, ld complains
ld: fatal: file miniperlmain.o: wrong ELF class: ELFCLASS64
That means that ld has seen something earlier that was LP32. I'll
bet it was a gcc-specific crt1.o or crtbegin.o. If I recall correctly,
gcc adds those start-up files to the ld command line. If they are
32-bit, then you'll get the error message above.
If I'm right, the culprit is this bit in the current hints/solaris_2.sh
file:
# no changes to ld flags, as (according to man ld):
#
# There is no specific option that tells ld to link 64-bit
# objects; the class of the first object that gets processed
# by ld determines whether it is to perform a 32-bit or a
The problem is that $ldflags are sent to $ld, which is actually $cc on
Solaris (as well as on most modern Unix systems). (It really was ld on
SunOS 4.1.3, where this part of Configure was designed, and the name
has stuck.)
In brief, although /usr/ccs/bin/ld doesn't need any specific flags, gcc
does need to know which set of start-up files to send to
/usr/ccs/bin/ld, so gcc *does* need a flag.
I don't have gcc-3.3 to test (my Solaris gcc installation is still
2.8.1), but I think the following patch should fix it:
--- perl-5.8.2/hints/solaris_2.sh Mon Oct 27 12:27:29 2003
+++ perl-5.8.2-andy/hints/solaris_2.sh Thu Nov 20 09:24:38 2003
@@ -516,14 +516,13 @@
loclibpth="/usr/lib/sparcv9 $loclibpth"
ccflags="$ccflags -mcpu=v9 -m64"
if test X`getconf XBS5_LP64_OFF64_CFLAGS 2>/dev/null` != X; then
+ # This adds in -Wa,-xarch=v9. I suspect that's superfluous,
+ # since the -m64 above should do that already. Someone
+ # with gcc-3.x.x, please test with gcc -v. A.D. 20-Nov-2003
ccflags="$ccflags -Wa,`getconf XBS5_LP64_OFF64_CFLAGS 2>/dev/null`"
fi
- # no changes to ld flags, as (according to man ld):
- #
- # There is no specific option that tells ld to link 64-bit
- # objects; the class of the first object that gets processed
- # by ld determines whether it is to perform a 32-bit or a
- # 64-bit link edit.
+ ldflags="$ldflags -m64"
+ lddlflags="$lddlflags -m64"
;;
*)
ccflags="$ccflags `getconf XBS5_LP64_OFF64_CFLAGS 2>/dev/null`"
Hope this helps,
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next