On Aug 26, 2004, at 8:25 AM, Peter Schmid wrote:
[snipped]
> >> ../../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.
>
> Agreed..but a bug in all the compilers (PGI, GCC, Intel.. and 2
> versions of Intel and PGI).. seems strange.
True. The linker explanation sounds plausible, though. I don't have
this kind of hardware to test on, so I'm fairly clueless here. :-\
> > 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)
>
> Yes I can.. no problem (with the GCC AMD version at least):
Just as a test, you might want to make another .a file with a similar
number of bogus symbols and see what happens if you try to link to it
(i.e., outside of LAM and/or MPI). A clever shell script could output
a .c file with a huge number of symbols that you could compile into a
.a file and see what happens.
If that doesn't work, try emitting lots of .c files with lots of
symbols -- something similar to what we have in liblam (perhaps even
count the number of .o files and number of symbols and emulating
something similar). Doing all this may be a bit of grunt work, but if
you can get things to link successfully, then we'll have ruled out the
compiler/linker and it really will be a problem with LAM.
> What version of gcc is lam-7.0.6 built with for the RPMs available?
RedHat 9 (i.e., gcc 3.2, IIRC) -- they're 32 bit RPMs. See
http://www.lam-mpi.org/download/linux-rpms.php.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
