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-bounces_at_[hidden]
> [mailto:devel-bounces_at_[hidden]] On Behalf Of Ralf Wildenhues
> Sent: Tuesday, March 21, 2006 5:35 AM
> To: devel_at_[hidden]
> 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
> 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/timer/linux/libmca_timer_linux.la -lm -lutil -lnsl -lpthread
> | mkdir .libs
> | pgcc -shared -fpic -DPIC
> -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?
> devel mailing list