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

[Diab Jerius]

On Mon, 2012-01-09 at 11:11 -0600, Bob Friesenhahn wrote:
On Mon, 9 Jan 2012, Diab Jerius wrote:
> >>
> >> 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.
> 
> DESTDIR is ultimately an environment variable.  Regardless, using 
> AM_MAKEFLAGS to pass DESTDIR causes a split-personality disorder since 
> it would only be passed to the subordinate makes and the top Makefile 
> invocation will not see it.
> 
>> I suggest trying the 'make DESTDIR' approach instead.
> >
> > Thanks for the suggestion, but as noted above, DESTDIR is correctly set.
> 
> But it wasn't really.  It is pretty common for the top makefile to 
> handle quite a lot of the installation steps.  In a non-recursive 
> build (no subordinate directories/makefile), it would ideal for make 
> to not recurse at all and so an argument supplied via AM_MAKEFLAGS 
> would not get used at all.
> 

I have the impression that you and I are discussing different issues.

When I use the words "correctly set" I mean that DESTDIR is given the
value which I specified.  When you use the words "correctly set" are you
referring to the value or to the mechanism by which it is being set?

If the former than I can assure you that my intended value is being
propagated to the relevant subordinate make invocations correctly.  From
the other response to this thread it has become obvious that I'm
specifying an incorrect value of DESTDIR.

If instead you mean to point out that using AM_MAKEFLAGS on the make
command line is in general a poor idea, then that's a very different
thing with which I agree.  The build system which I use has had to
incorporate work-arounds for bugs (or perhaps misunderstandings on my
part) in the behavior of autotools in my environment over the years.  I
no longer recall why this particular behavior was encoded.  The
distributed packages' Makefiles do not require AM_MAKEFLAGS to be
specified on the make command line for DESTDIR to work properly.

Diab