At 11:57 PM 8/25/2004, Jeff Squyres wrote:
>On Aug 25, 2004, at 2:19 PM, Peter Schmid wrote:
>
>>I'm having trouble getting Lam-7.0.6 built from source for any 64-bit
>>platform. I have tried the following:
>>
>>AMD Opter RHEL AS 3.0:
>>
>>PGI compiler 5.1/5.2
>>gcc 3.2.3
>>
>>
>>SGI Altix 16 CPU Itanium
>>Intel 7.1/8.0
>>
>>I get the following error when I issue make:
>>Making all in lamclean
>>make[2]: Entering directory `/hpc/user/schmid/lam-7.0.6/otb/lamclean'
>>if gcc -DHAVE_CONFIG_H -I. -I. -I../../share/include
>>-I../../share/include -DLAM_BUILDING=1 -O3 -pthread -MT lamclean.o
>>-MD -MP -MF ".deps/lamclean.Tpo" -c -o lamclean.o lamclean.c; \
>>then mv -f ".deps/lamclean.Tpo" ".deps/lamclean.Po"; else rm -f
>>".deps/lamclean.Tpo"; exit 1; fi
>>/bin/sh ../../libtool --mode=link gcc -O3 -pthread -o lamclean
>>lamclean.o ../../share/liblam.la -lutil
>>gcc -O3 -pthread -o lamclean lamclean.o ../../share/.libs/liblam.a -lutil
>>../../share/.libs/liblam.a: could not read symbols: Memory exhausted
>>collect2: ld returned 1 exit status
>>make[2]: *** [lamclean] Error 1
>
>Yikes. This *looks* like a bug in the compiler -- the compiler should not
>run out of memory when linking. There aren't *that* many symbols in liblam.
>
>Can you run "nm" successfully on share/.libs/liblam.a? (the .libs
>directory is a temporary working directory that Automake uses to for
>building intermediate libraries before they're installed)
If there is an out of memory while linking, it's not the compiler, it's the
linker. I saw such problems frequently last year when attempting to link
with only 1GB RAM installed. The x86-64 OS is quite memory hungry, compared
to its 32-bit relatives. Apparently, the early versions of ld for x86-64
had to read the entire .a symbol table, and those are twice as big as in a
32-bit OS.
Tim Prince
|
