[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cannot a directory not ending in

From: Jeff Blaine
Subject: Re: cannot a directory not ending in
Date: Fri, 22 Sep 2006 12:30:42 -0400
User-agent: Thunderbird (Windows/20060909)

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 :)

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 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.


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 install prefix=/my/to-be-released/destination

Not with Libtool-using packages, at least not bug-free, as far as I

 make install DESTDIR=/my/staging/directory

works to install your stuff temporarily into

from where it can be moved to

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

but are to finally appear at

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]