On Sat, 2012-01-07 at 13:31 -0600, Bob Friesenhahn wrote: > On Fri, 6 Jan 2012, Diab Jerius wrote: > > > > and the installation is performed via > > > > make AM_MAKEFLAGS="DESTDIR=/proj/axaf/simul/pkgs > > prefix=/lua_udunits2-0.1.2_01 > > exec_prefix=/lua_udunits2-0.1.2_01/x86_64-linux_debian-5.0" install > > Why do you use > > make AM_MAKEFLAGS="DESTDIR=... > > rather than > > make DESTDIR=... > > ? > > Where is such use of AM_MAKEFLAGS documented?
It may not have been obvious in my original email, but I'm using automake. AM_MAKEFLAGS is provided by automake. From the automake documentation: When Automake invokes `make' in a subdirectory, it uses the value of the `MAKE' variable. It passes the value of the variable `AM_MAKEFLAGS' to the `make' invocation; this can be set in `Makefile.am' if there are flags you must always pass to `make'. In my environment this has proven to be necessary to ensure that recursive makefiles are passed the correct information. In any case, the key point is that DESTDIR is correctly set, regardless of the mechanism. > > > This results in a libtool invocation of > > > > /bin/sh ../libtool --mode=install /usr/bin/install -c udunits2.la > > '/proj/axaf/simul/pkgs/lua_udunits2-0.1.2_01/x86_64-linux_debian-5.0/lib/lua/5.1' > > > > which fails with: > > > > libtool: install: error: cannot install `udunits2.la' to a directory > > not ending in /proj/axaf/simul/x86_64-linux_debian-5.0/lib/lua/5.1 > > > > I believe the problem is that I'm linking the dlopen'able module against > > a library which hasn't yet been installed (as it is part of the > > distribution). I haven't been able to distill anything from the libtool > > documentation which would touches upon this issue. > > It seems more like libtool is refusing to install the .la file to a > directory other than where it is supposed to reside. If you look > inside the .la file, you will see that it even records the directory > where it is supposed to reside. I have a number of library distributions using automake and libtool, and have never had a problem with libtool installing the libraries into the staging area. The only difference between those distributions and the problematic one is that they install a single library. This is the first distribution I've created which installs two dynamic libraries, one of which depends upon the other, which is why I believe that the problem lies there. The libtool code provides some insight, but I don't understand enough about the rationale behind the code. libtool only refuses to install if there is a relink command embedded in the .la file. As far as I can tell the relink command is in the .la file because it cannot completely resolve the dependencies until the installation step. Here's the relevant code from the libtool generated for my distribution: 3378 if test -n "$relink_command"; then 3379 # Determine the prefix the user has applied to our future dir. 3380 inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"` 3381 3382 # Don't allow the user to place us outside of our expected 3383 # location b/c this prevents finding dependent libraries that 3384 # are installed to the same prefix. 3385 # At present, this check doesn't affect windows .dll's that 3386 # are installed into $libdir/../bin (currently, that works fine) 3387 # but it's something to keep an eye on. 3388 test "$inst_prefix_dir" = "$destdir" && \ 3389 func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir" 3390 3391 if test -n "$inst_prefix_dir"; then 3392 # Stick the inst_prefix_dir data into the link command. 3393 relink_command=`$ECHO "$relink_command" | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" 3393 ` 3394 else 3395 relink_command=`$ECHO "$relink_command" | $SED "s%@inst_prefix_dir@%%"` 3396 fi 3397 3398 func_warning "relinking \`$file'" 3399 func_show_eval "$relink_command" \ 3400 'func_fatal_error "error: relink \`$file'\'' with the above command before installing it"' 3401 fi The conditional is at line 3388 and is triggered only in the presence of a relink command. > > > Is this the correct diagnosis and is there a fix? > > I suggest trying the 'make DESTDIR' approach instead. Thanks for the suggestion, but as noted above, DESTDIR is correctly set. _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool