Re: [OMPI devel] PG 5.2 build problem with v1.0.2a10'
Hi Josh, * Josh Hursey wrote on Mon, Mar 20, 2006 at 06:48:55PM CET: > On Mar 20, 2006, at 12:13 PM, Ralf Wildenhues wrote: > >* Josh Hursey wrote on Mon, Mar 20, 2006 at 06:05:29PM CET: > >>I recently ran into a build problem using the Portland 5.2 compilers > >>on Odin (x86_64). It looks like the soft link is broken in the build > >>system. > >>It is linked to libopal.so.0.0.0 instead of libopal.so.0 > > > >Do you still have the complete build log? The place where libopal is > >created is interesting, as well as './libtool --config'. > > Sorry I forgot to include that. Should be attached now. Hmm. Could you go into $top_builddir/opal and do ../libtool --mode=clean rm -f libopal.la make 2>&1 | tee makelog and send makelog? After that, the .libs subdirectory should look more or less like this (the *.la* may vary a bit): libopal.la -> ../libopal.la libopal.lai libopal.so -> libopal.so.0.0.0 libopal.so.0 -> libopal.so.0.0.0 libopal.so.0.0.0 Otherwise, I cannot detect much that looks suspicious. This is weird, but it looks unrelated: | configure:130244: checking whether a statically linked program can dlopen itself | configure:130318: pgcc -o conftest -O -DNDEBUG-D_REENTRANT -DHAVE_DLFCN_H -Wl,--export-dynamic -Bstatic conftest.c -ldl -lm -lutil -lnsl -lpthread >&5 | /tmp/pgccbpoxac.o(.text+0x28): In function `main': | : warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | configure:130321: $? = 0 | /u/jjhursey/local/odin/ompi/devel/lib/: cannot read file data: Is a directory | configure:130339: result: no Thanks, Ralf
Re: [OMPI devel] PG 5.2 build problem with v1.0.2a10
* Josh Hursey wrote on Mon, Mar 20, 2006 at 06:48:55PM CET: > On Mar 20, 2006, at 12:13 PM, Ralf Wildenhues wrote: > > > >Do you still have the complete build log? The place where libopal is > >created is interesting, as well as './libtool --config'. > > Sorry I forgot to include that. Should be attached now. Wait.. you `./libtool --config' output has: | # Libtool was configured on host crowe.devel.redhat.com: That's presumably from /usr/bin/libtool, and contains gcc as compiler instead of pgcc. Let's see the output from $top_builddir/libtool. Cheers, Ralf
Re: [OMPI devel] PG 5.2 build problem with v1.0.2a10
The files should be attached. Cheers, josh pg-5-2.tar.bz2 Description: Binary data On Mar 21, 2006, at 7:45 AM, Ralf Wildenhues wrote: * Josh Hursey wrote on Mon, Mar 20, 2006 at 06:48:55PM CET: On Mar 20, 2006, at 12:13 PM, Ralf Wildenhues wrote: Do you still have the complete build log? The place where libopal is created is interesting, as well as './libtool --config'. Sorry I forgot to include that. Should be attached now. Wait.. you `./libtool --config' output has: | # Libtool was configured on host crowe.devel.redhat.com: That's presumably from /usr/bin/libtool, and contains gcc as compiler instead of pgcc. Let's see the output from $top_builddir/libtool. Cheers, Ralf ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel Josh Hursey jjhur...@open-mpi.org http://www.open-mpi.org/
Re: [OMPI devel] PG 5.2 build problem with v1.0.2a10
* Josh Hursey wrote on Tue, Mar 21, 2006 at 02:20:54PM CET: > >>On Mar 20, 2006, at 12:13 PM, Ralf Wildenhues wrote: > >>> > >>>Do you still have the complete build log? The place where > >>>libopal is > >>>created is interesting, as well as './libtool --config'. > The files should be attached. Ahh. That explains it: | /bin/sh ../libtool --tag=CC --mode=link pgcc -O -DNDEBUG-export-dynamic -o libopal.la -rpath /san/homedirs/jjhursey/local/odin//ompi/release/lib libltdl/libltdlc.la asm/libasm.la class/libclass.la event/libevent.la mca/base/libmca_base.la memoryhooks/libopalmemory.la runtime/libruntime.la threads/libthreads.la util/libopalutil.la mca/maffinity/base/libmca_maffinity_base.la mca/memory/base/libmca_memory_base.la mca/memory/malloc_hooks/libmca_memory_malloc_hooks.la mca/paffinity/base/libmca_paffinity_base.la mca/timer/base/libmca_timer_base.la mca/timer/linux/libmca_timer_linux.la -lm -lutil -lnsl -lpthread | mkdir .libs | pgcc -shared -fpic -DPIC -Wl,--whole-archive,libltdl/.libs/libltdlc.a,asm/.libs/libasm.a,class/.libs/libclass.a,event/.libs/libevent.a,mca/base/.libs/libmca_base.a,memoryhooks/.libs/libopalmemory.a,runtime/.libs/libruntime.a,threads/.libs/libthreads.a,util/.libs/libopalutil.a,mca/maffinity/base/.libs/libmca_maffinity_base.a,mca/memory/base/.libs/libmca_memory_base.a,mca/memory/malloc_hooks/.libs/libmca_memory_malloc_hooks.a,mca/paffinity/base/.libs/libmca_paffinity_base.a,mca/timer/base/.libs/libmca_timer_base.a,mca/timer/linux/.libs/libmca_timer_linux.a -Wl,--no-whole-archive -ldl -lm -lutil -lnsl -lpthread -lc -Wl,-soname -Wl,libopal.so.0 -o .libs/libopal.so.0.0.0 | pgcc-Warning-No files to process PGI/5.2 does not like it when it's not given any object file, and it's supposed to invoke the linker. It does not see the libraries, as they are all hidden as arguments to be passed to the linker. This has been fixed since in PGI/6.0 and 6.1. Nevertheless, there are probably more compilers which can fail in this way. I added a test to this extent to the CVS version of Libtool a while ago, in order to gain more knowledge about this. The gist is: this could *probably* be worked around inside libtool. But it would not solve all issues, when looking at the bigger picture of Libtool+Automake interaction. Why is that? Well, you write libfoo_la_SOURCES = libfoo_la_LIBADD = libbar1.la libbar2.la ... but then Automake does not really know which language (compiler) to use for linking libfoo. And this second issue is not so trivial to solve inside the autotools. But an easy workaround for the moment is to either add a dummy source file to libfoo_la_SOURCES, or change one of the convenience archives libbar* added into just the objects being added. I did not notice this issue here, because the OpenMPI trunk does exactly the latter (for example through opal/class/Makefile.am, which is included in opal/Makefile.am), and I do not follow branches much. Does that help? Cheers, Ralf
Re: [OMPI devel] PG 5.2 build problem with v1.0.2a10
I vote we don't worry about this for 1.0.x. Does anyone care about PGI 5.2 in 1.0.x? If so, is it a quick/easy fix to the Makefile.am to do what Ralf proposes (and we apparently already do something similar on the trunk)? > -Original Message- > From: devel-boun...@open-mpi.org > [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralf Wildenhues > Sent: Tuesday, March 21, 2006 5:35 AM > To: de...@open-mpi.org > Subject: Re: [OMPI devel] PG 5.2 build problem with v1.0.2a10 > > * Josh Hursey wrote on Tue, Mar 21, 2006 at 02:20:54PM CET: > > >>On Mar 20, 2006, at 12:13 PM, Ralf Wildenhues wrote: > > >>> > > >>>Do you still have the complete build log? The place where > > >>>libopal is > > >>>created is interesting, as well as './libtool --config'. > > > The files should be attached. > > Ahh. That explains it: > > | /bin/sh ../libtool --tag=CC --mode=link pgcc -O -DNDEBUG > -export-dynamic -o libopal.la -rpath > /san/homedirs/jjhursey/local/odin//ompi/release/lib > libltdl/libltdlc.la asm/libasm.la class/libclass.la > event/libevent.la mca/base/libmca_base.la > memoryhooks/libopalmemory.la runtime/libruntime.la > threads/libthreads.la util/libopalutil.la > mca/maffinity/base/libmca_maffinity_base.la > mca/memory/base/libmca_memory_base.la > mca/memory/malloc_hooks/libmca_memory_malloc_hooks.la > mca/paffinity/base/libmca_paffinity_base.la > mca/timer/base/libmca_timer_base.la > mca/timer/linux/libmca_timer_linux.la -lm -lutil -lnsl -lpthread > | mkdir .libs > | pgcc -shared -fpic -DPIC > -Wl,--whole-archive,libltdl/.libs/libltdlc.a,asm/.libs/libasm. a,class/.libs/libclass.a,event/.libs/libevent.a,mca/base/.libs/libmca_ba se.a,memoryhooks/.libs/libopalmemory.a,ru> ntime/.libs/libruntime.a,threads/.libs/libthreads.a,util/.libs > /libopalutil.a,mca/maffinity/base/.libs/libmca_maffinity_base. > a,mca/memory/base/.libs/libmca_memory_base.a,mca/memory/malloc > _hooks/.libs/libmca_memory_malloc_hooks.a,mca/paffinity/base/. > libs/libmca_paffinity_base.a,mca/timer/base/.libs/libmca_timer > _base.a,mca/timer/linux/.libs/libmca_timer_linux.a > -Wl,--no-whole-archive -ldl -lm -lutil -lnsl -lpthread -lc > -Wl,-soname -Wl,libopal.so.0 -o .libs/libopal.so.0.0.0 > | pgcc-Warning-No files to process > > PGI/5.2 does not like it when it's not given any object file, and it's > supposed to invoke the linker. It does not see the libraries, as they > are all hidden as arguments to be passed to the linker. This has been > fixed since in PGI/6.0 and 6.1. > > Nevertheless, there are probably more compilers which can fail in this > way. I added a test to this extent to the CVS version of Libtool a > while ago, in order to gain more knowledge about this. > > The gist is: this could *probably* be worked around inside libtool. > But it would not solve all issues, when looking at the bigger picture > of Libtool+Automake interaction. > > Why is that? Well, you write > libfoo_la_SOURCES = > libfoo_la_LIBADD = libbar1.la libbar2.la ... > > but then Automake does not really know which language > (compiler) to use > for linking libfoo. And this second issue is not so trivial to solve > inside the autotools. > > But an easy workaround for the moment is to either add a dummy source > file to libfoo_la_SOURCES, or change one of the convenience archives > libbar* added into just the objects being added. > > I did not notice this issue here, because the OpenMPI trunk > does exactly > the latter (for example through opal/class/Makefile.am, which is > included in opal/Makefile.am), and I do not follow branches much. > > Does that help? > > Cheers, > Ralf > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
