libtool-patches
[Top][All Lists]
Advanced

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

Re: bindir for libtool


From: Charles Wilson
Subject: Re: bindir for libtool
Date: Fri, 28 Aug 2009 17:52:19 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

Roumen Petrov wrote:
> I would like to share code and test case performed by me to add "bindir"
> support to libtool.
> The patch for libtool is attached as file "libtool-origin-bindir.patch".
> The patch propose absolute path for dlname in la-file.

Thank you for following through on this.

> The attached file "bootstrap.sh" is the test case for a dlopen
> application. Bootstrap script apply following patched to test source tree .
> - libtool-libltdl.patch (non required . help to trace dlopen)
> - makefile-bindir_rule.patch - changed to automake rules, i.e. add
> bindir flag to libtool.

It would be better if the testcase were implemented as part of the
automated testsuite, rather than as a standalone test.  However, I
understand wanting to get some feedback on the code, before spending
more time integrating the test.

> Charles Wilson in mails threads add a note that for "GNU Coding Standard".
> Libtool create lai-files in link mode. So in install mode is too late to
> change prefix,bindir or libdir. "libdir" in installed la-file point to
> "libdir" directory as is set before in link mode.

Well, yeah:  The GNU Coding Standard should allow us to do this, for any
package that uses libtool (well, for *any* package, but we only care
about the ones that use libtool on /this/ list!)

  $ configure --prefix=/foo && make
  $ make install prefix=/some/tmp/dir/foo

and the .la files in /some/tmp/dir/foo/lib/* should contain paths that
use the *original* /foo, and not updated to the new "fake" prefix.  If I
understand the GCS correctly.

> For install mode the above patch install libraries in correct location -
> "libdir" for library related files and DLL in "bindir". Note that
> "libdir" in la-file left unchanged during install. As result dll can't
> be found even dlname contain relative path. I'm addressing the simple
> case when user try to override prefix for install.

Well, this is a bit unfair to you Roumen, but...given that (a) the
*primary* motivation for fixing this, right this minute, is so that
gcc-4.5.0 can get this fix in time for the end of stage 1 (this
weekend), and (b) gcc has already merged Dave's patch:
   http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01073.html

I believe that the best way forward *for now* is for libtool to accept
Dave's version -- even though it doesn't fix the problem case *you* are
concerned about.  This should help ease merging gcc<-->libtool down the
road, especially if we THEN add some additional changes, somewhat along
the lines of your suggestion, which gcc can pick up and easily merge
*after* their stage 1 closes.

I realize this is a bit of "tail wagging the dog" (why should gcc's
modifying their semi-fork of libtool affect how we modify the official
version?) but (a) gcc is, honestly, a REALLY BIG "tail", and (b) libtool
is a relatively small "dog", so it does make some sense to accommodate
their needs -- especially as Ralf has been intimately involved over the
last months updating gcc's autoconf/automake/(libtool?) support.

My preference going forward would be:

  1) assuming no further objections (and, I believe Dave has adequately
address ALL objections /except/ Roumen's), merge Dave's patch forthwith.

  2) Begin a discussion about how to accommodate Roumen's concerns,
which have not been addressed by Dave's changes, but without breaking
Dave's (that is, gcc's) use of the -bindir option.

I'd suggest, perhaps, adding a *different* libtool option, e.g.
-abs-bindir, that works semantically as Roumen desires. Then, later, gcc
may choose to use either -bindir or -abs-bindir, whatever seems best to
them. I'm probably overlooking something with this suggestion, but I'd
prefer if, rather than extending this thread and delaying #1 above any
longer, we postpone discussion of how what I've just said is all wrong
until after #1, and we're into the discussion of #2.

--
Chuck




reply via email to

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