Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] VT support for 1.5
From: Matthias Jurenz (matthias.jurenz_at_[hidden])
Date: 2011-06-22 10:29:09


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.