Re: cannot install...to a directory not ending in

[Jeff Blaine]

Hi Ralf and Ed,

Ed's description of the problem is what I am experiencing.
We use VECT (aka "CMU's EMT Rewritten and made "Lite") for
release management of apps.  Written by yours truly :)

http://vect.sourceforge.net/

Anyway, it's the same problematic idea as Stow's.

I will try --with-libdir, however I'm immediately concerned
that it's going to cause an additional problem:  We don't
want anything we build for /dest to have any references
to /dest/stow/<package>-<package version> (to use Ed's
example).  We often gather up /dest in a tarball to drop
onto non-networked machines, for example.  They exist :)

I bet building gcc (for example) with --with-libdir=
is going to cause that.

Ralf - sorry I came across so frustrated.  I just hate when
tools stop me from doing what I know is correct.  That is,
yes, once the app is released, the libraries *will* live
where libtool wants them.  Just let me install them elsewhere
and handle it.  As for an appropriate solution (assuming
--with-libdir doesn't turn out to be a royal pain to get
going), I'd be happy with any environmental flag that
would turn those 'fatal errors' into warnings.

Edward Maros wrote:
> I believe the problem being described here is one that I have 
> encountered also since I use stow for package management. A long time 
> ago, it use to be the case you could say:
>
> ./configure --prefix=/dest
> make
> make prefix=/dest/stow/<package>-<package version> install
>
> even if the package installed shared objects.
>
> With more recent versions of libtool, I have had to add the 
> --with-libdir=/dest/stow/<package>-<package version>/lib to allow proper 
> installation.
>
> Ed
>
> Ralf Wildenhues wrote:
>
> > Hello Jeff,
> >
> > * Jeff Blaine wrote on Fri, Sep 22, 2006 at 04:17:07PM CEST:
> >  
> >
> > > Okay, I've run into this enough that it's taken its toll
> > > on me and I must know the proper modern way to handle this.
> > >   
> >
> > Hmm.  This sounds like it used to work before and we broke something.
> > Is it what you are implying?
> >
> >  
> >
> > > For years and years, the following worked fine for any
> > > GNU app using autoconf:
> > >
> > >     ./configure --prefix=/my/final/destination
> > >     make
> > >     make install prefix=/my/to-be-released/destination
> > >   
> >
> > Not with Libtool-using packages, at least not bug-free, as far as I
> > remember.
> >
> >  make install DESTDIR=/my/staging/directory
> >
> > works to install your stuff temporarily into
> >  /my/staging/directory/my/final/destination
> >
> > from where it can be moved to
> >  /my/final/destination
> >
> > and, after a  libtool --mode=finish /my/final/destination/lib
> >
> > libraries should be useable.
> >
> > There are issues in current libtool that prevent this from working
> > properly in _some_ cases when you try to link against third-party
> > libraries that currently are visible below
> >  /my/staging/directory/my/final/destination
> >
> > but are to finally appear at
> >  /my/final/destination/
> >
> > See some other discussion on this list just this week.
> >
> >  
> >
> > > It has often not worked when involving libtool over the
> > > last year or two and it's driving me nuts.  Can someone
> > > PUHLEEEEZE tell me the right way to do this?
> > >   
> >
> > Well, I'm really sorry you've had so much trouble, and I can only ask to
> > report issues earlier.  If you think there is a regression involved then
> > please point me to a package where this should have worked.
> >
> > Hope that helps.
> >
> > Cheers,
> > Ralf
> >
> >
> > _______________________________________________
> > http://lists.gnu.org/mailman/listinfo/libtool
> >