Hi,
I think I've figured out what might be going on here. In libtool the
compiler flag to generate shared objects directly from archives was set to
-z allextract\$convenience -z defaultextract
however I believe -z defaultextract has been depreciated in gcc. I
changed the above line to read
-Wl,-z -Wl,allextract\$convenience -Wl,-z -Wl,defaultextract
to pass these expressions to the linker and it now appears to be working
fine.
Thanks for the help
Jason
On Tue, 19 Oct 2004, Jeff Squyres wrote:
> No, your problem does not seem to be related to -lrt -- the symbols
> that you're not finding are in LAM itself, not a system library. All
> of those symbols should be able to be found in share/.lib/liblam.so.
> Can you nm on that library and see if they're there? If they're not,
> were there previous warnings or errors in the "make" output that
> indicated why they're not there?
>
> I have seen this kind of thing on Solaris when mixing 32 and 64 bit
> objects -- at least at some point a year or three ago, the error
> messages from the Solaris compiler were quite un-helpful, saying that
> symbols were not found when in fact the error was actually a mismatch
> of 32/64 -- the symbols *did* exist, but they were in the other size
> than what was being looked for (e.g., if you did an nm on the library,
> you would see the symbols, leading to lots of head scratching as to why
> ld would not find them). You're using gcc 3.4 here, so I don't know if
> this is a factor or not (are you using the GNU ld or Solaris ld?), but
> I bring it up just in case...
>
> Can you send the full set of debugging information listed on
> http://www.lam-mpi.org/using/support/?
>
>
> On Oct 19, 2004, at 10:49 AM, Jason.Beech-Brandt_at_[hidden] wrote:
>
> > Hi,
> >
> > I'm having trouble compiling lam-7.0.6 on a Sun Sparc machine running
> > Solaris 8. I'm using gcc-3.4.2 as my compiler and enabling shared
> > libraries. The problem is that when I get to a certain point in the
> > compilation where lamclean.o is trying to be built, a number of
> > undefined
> > symbols pop up. Specifically I get,
> >
> > gcc -O3 -o .libs/lamclean lamclean.o ../../share/.libs/liblam.so
> > -lsocket
> > -lnsl -lrt -lthread
> > -R/home/jbbrand1/foam/foam2.3/src/lam-7.0.6/platforms/
> > solarisGcc34OptLAM/lib
> > Undefined first referenced
> > symbol in file
> > opt_taken lamclean.o
> > rbfwipe lamclean.o
> > do_args lamclean.o
> > show_help lamclean.o
> > kexit lamclean.o
> > validopts lamclean.o
> > nodespin_end lamclean.o
> > nodespin_init lamclean.o
> > kinit lamclean.o
> > lam_rfrmfd lamclean.o
> > lam_rtrcleanobjs lamclean.o
> > lam_rtrsweep lamclean.o
> > getnodes lamclean.o
> > rpdoom lamclean.o
> > lamfail lamclean.o
> > nodespin_next lamclean.o
> > getntype lamclean.o
> > ld: fatal: Symbol referencing errors. No output written to
> > .libs/lamclean
> > collect2: ld returned 1 exit status
> > gmake[2]: *** [lamclean] Error 1
> > gmake[2]: Leaving directory
> > `/home/jbbrand1/foam/foam2.3/src/lam-7.0.6/otb/lamclean'
> > gmake[1]: *** [all-recursive] Error 1
> > gmake[1]: Leaving directory
> > `/home/jbbrand1/foam/foam2.3/src/lam-7.0.6/otb'
> > gmake: *** [all-recursive] Error 1
> >
> > Now, I notice a previous user had an almost identical problem. The
> > remedy
> > at the time was to do a clean build with the additional flag LIBS=-lrt
> > at
> > the configure stage. That's what I've done here. However, it does not
> > seem to work for me. Unfortunately, the thread with the previous user
> > seems to come to an end before we find out if the procedure outlined
> > worked for them. Any ideas on how what I might be doing wrong?
> >
> > Thanks in advance for the help.
> >
> > Jason
> > _______________________________________________
> > This list is archived at http://www.lam-mpi.org/MailArchives/lam/
> >
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
|
