abs-bindir Was: bindir for libtool
Ralf Wildenhues wrote: Hi Charles, [SNIP] I agree. 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. We can think about -abs-bindir. #1 is waiting to be committed to GNU Libtool only for the finishing of DaveK's copyright papers; then I will commit it (along with a couple of fixes, one of which has shown up in GCC already and the other is in Libtool testsuite-only code). Just updated to master, but without tests - I don't have time to write them , may be next month :( Regards diff --git a/ChangeLog b/ChangeLog index caf125a..ebabba8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,16 @@ +2009-09-28 Roumen Petrov bugtr...@roumenpetrov.info + + Control where to place shared libraries for system without + shared library path variable different from PATH. + * libltdl/config/ltmain.m4sh (func_mode_help): + Document -abs-bindir. + (func_mode_link, func_mode_install, func_mode_uninstall): + Accept new -abs-bindir option and use it, if supplied. + * libltdl/m4/libtool.m4: support absolute path for DLLs. + Pass environment variable DESTDIR to post{un}install commands. + * libltdl/ltdl.c: support absolute path for dynamic module. + * NEWS: Update. + 2009-11-01 Ralf Wildenhues ralf.wildenh...@gmx.de Fix func_normal_abspath sed script for Solaris. diff --git a/NEWS b/NEWS index 80f0413..d0b88a1 100644 --- a/NEWS +++ b/NEWS @@ -16,6 +16,8 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team: runs on Windows with popup windows in the middle, and `check-interactive' for the complement set of tests. - New link mode flag -bindir to specify the location for installed PE DLLs. + - New flag -abs-bindir for modes link,install,uninstall to specify the +absolute location for installed PE DLLs. * Changes in supported systems or compilers: diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 91d0800..0a17a41 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -1112,7 +1112,9 @@ The following components of INSTALL-COMMAND are treated specially: -inst-prefix-dir PREFIX-DIR Use PREFIX-DIR as a staging area for installation The rest of the components are interpreted as arguments to that command (only -BSD-compatible install options are recognized). +BSD-compatible install options are recognized). Exception is argument +\`-abs-bindir'. This argument specify where to place shared libraries(DLLs) +for system without shared library path variable different from PATH. ;; link) @@ -1131,6 +1133,11 @@ The following components of LINK-COMMAND are treated specially: -avoid-versiondo not add a version suffix if possible -bindir BINDIRspecify path to binaries directory (for systems where libraries must be found in the PATH setting at runtime) + -abs-bindir ABS_BINDIR +specify path to binaries directory (for system without +shared library path variable different from PATH). +Symilar to -bindir but without internal relative path +calculation. -dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3) @@ -1191,6 +1198,12 @@ Remove libraries from an installation directory. RM is the name of the program to use to delete files associated with each FILE (typically \`/bin/rm'). RM-OPTIONS are options (such as \`-f') to be passed to RM. +The following components of RM-OPTIONS are treated specially: + + -abs-bindir ABS_BINDIR + Use ABS_BINDIR to find shared libraries (DLLs) for system without + shared library path variable different from PATH. Used only if + FILE is a libtool library. If FILE is a libtool library, all the files associated with it are deleted. Otherwise, only FILE itself is deleted using RM. @@ -1451,6 +1464,9 @@ test $mode = finish func_mode_finish ${1+$@} # func_mode_install arg... func_mode_install () { +inst_destdir= +test -n $DESTDIR inst_destdir=$DESTDIR + $opt_debug # There may be an optional sh(1) argument at the beginning of # install_prog (especially on Windows NT). @@ -1477,6 +1493,10 @@ func_mode_install () *) install_cp=false ;; esac +# heuristic location of shared libraries for system without +# shared library path variable different from PATH +dlbindir=../bin + # We need to accept at least
Re: bindir for libtool
Hi Charles, thanks for chiming in. * Charles Wilson wrote on Fri, Aug 28, 2009 at 11:52:19PM CEST: 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 agree. 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. We can think about -abs-bindir. #1 is waiting to be committed to GNU Libtool only for the finishing of DaveK's copyright papers; then I will commit it (along with a couple of fixes, one of which has shown up in GCC already and the other is in Libtool testsuite-only code). Cheers, Ralf
Re: bindir for libtool
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
bindir for libtool
Hi All, 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. 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. 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. 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. Regards, Roumen diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index d8c5749..c1c6acc 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially: -all-static do not do any dynamic linking at all -avoid-versiondo not add a version suffix if possible + -bindir BINDIRspecify path to binaries directory (for systems where +libraries must be found in the PATH setting at runtime) -dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3) @@ -1475,6 +1477,10 @@ func_mode_install () *) install_cp=false ;; esac +# heuristic location of shared libraries for system without +# shared library path variable different from PATH +dlbindir=../bin + # We need to accept at least all the BSD install flags. dest= files= @@ -1507,16 +1513,29 @@ func_mode_install () stripme= -s continue ;; + -bindir) + prev=bindir + continue + ;; -*) ;; *) # If the previous option needed an argument, then skip it. if test -n $prev; then + case $prev in + bindir) + dlbindir=$arg + prev= + continue + ;; + *) if test x$prev = x-m test -n $install_override_mode; then arg2=$install_override_mode no_mode=false fi prev= + ;; + esac else dest=$arg continue @@ -1696,7 +1715,9 @@ func_mode_install () # Do each command in the postinstall commands. lib=$destdir/$realname - func_execute_cmds $postinstall_cmds 'exit $?' + inst_prefix_dir= + test -n $DESTDIR inst_prefix_dir=$DESTDIR + func_execute_cmds inst_prefix_dir=$inst_prefix_dir~dlbindir=$dlbindir~$postinstall_cmds 'exit $?' fi # Install the pseudo-library for information purposes. @@ -3674,6 +3695,9 @@ func_mode_link () new_inherited_linker_flags= avoid_version=no +# heuristic location of shared libraries for system without +# shared library path variable different from PATH +dlbindir=../bin dlfiles= dlprefiles= dlself=no @@ -3766,6 +3790,11 @@ func_mode_link () esac case $prev in + bindir) + dlbindir=$arg + prev= + continue + ;; dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. @@ -4027,6 +4056,11 @@ func_mode_link () continue ;; + -bindir) + prev=bindir + continue + ;; + -dlopen) prev=dlfiles continue @@ -7721,7 +7755,8 @@ EOF # place dlname in correct position for cygwin tdlname=$dlname case $host,$output,$installed,$module,$dlname in - *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;; + *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) + tdlname=$dlbindir/$dlname;; esac $ECHO $output \ # $outputname - a libtool library file @@ -7793,16 +7828,33 @@ func_mode_uninstall () rmforce= exit_status=0 +# heuristic location of shared libraries for system without +# shared library path variable different from PATH +dlbindir=../bin + # This variable tells wrapper scripts just to set variables rather # than running their programs. libtool_install_magic=$magic +prev= for arg do case $arg in + -bindir) +prev=bindir +continue +;; -f) RM=$RM $arg; rmforce=yes ;; -*) RM=$RM $arg ;; - *) files=$files $arg ;; + *) +case $prev in + bindir) +dlbindir=$arg +prev= +continue