On Jun 22, 2011, at 10:29 AM, Matthias Jurenz wrote:
> 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
> 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
>> 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.
>>> 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.
> devel mailing list
For corporate legal information go to: