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