libtool
[Top][All Lists]
Advanced

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

Re: dlopen, DESTDIR, library dependencies and "cannot install" error


From: Diab Jerius
Subject: Re: dlopen, DESTDIR, library dependencies and "cannot install" error
Date: Mon, 09 Jan 2012 09:50:30 -0500

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 
"address@hidden@%-inst-prefix-dir $inst_prefix_dir%"   3393 `
   3394           else
   3395             relink_command=`$ECHO "$relink_command" | $SED 
"address@hidden@%%"`
   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.





reply via email to

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