The CMR #2814 fixes the problem by renaming the internal VT library 'libutil.a' to 'libvt_util.a' to prevent name conflicts with dependency libraries.
I believe that's the safest way even I preferred the libtool patch. I'm not sure whether the patch is correct or not - it may break some other functionality. Matthias On Friday 10 June 2011 15:29:08 Jeff Squyres wrote: > On Jun 10, 2011, at 5:16 AM, Matthias Jurenz wrote: > > There are different ways to fix the problem: > > > > 1. Apply the attached patch on ltmain.sh. > > > > This patch excludes the target library name from searching *.la > > libraries. > > Does your patch work for vpath builds, too? If so, isn't this something > that should be submitted upstream? > > > 2. Rename the VT's libutil > > > > This would prevents name conflicts with dependency libraries. > > This is my preference; can't it just be renamed to libvtutil or something? > > > 3. Clear list of dependency libraries when building VT's libutil. > > > > This could be done by adding LIBS= to the Makefile.am in > > ompi/contrib/vt/vt/util/. The VT's libutil has no dependencies to other > > libraries except libc. > > That seems like it would work, but feels a bit hack-ish. > > > 4. Perform "make clean" or remove ompi/contrib/vt/vt/util/libutil.la > > after re- configure. > > > > Nonsense - it cannot be required from the user. > > Agreed. > > > My favorite suggestion is 1. It would be just another patch in addition > > to the set of Libtool patches invoked by autogen. > > Keep in mind that most (all?) of those are for handling older versions of > the GNU Autotools, and/or for patches that have been submitted upstream > but are not part of an official release yet. Or, they are for v1.5.x > where we have "locked in" the versions of the GNU autotools for the entire > series and won't upgrade, even if never versions fix the things we've put > in patches for.
