bug#9728: Incorrect -L flags order for HP-UX

[Bob Friesenhahn]

On Fri, 14 Oct 2011, Vincent Lefevre wrote:
> > Actually, the user should be allowed to shoot themselves in the foot
> > if they request it.
>
> Perhaps, but then, I think that if the user has a good reason to
> do this, then it should be able to override the settings done at
> configure time. So, --with-gmp=DIR should modify LDFLAGS, not
> AM_LDFLAGS, because as $(AM_LDFLAGS) appears before $(LDFLAGS),
> there would be no way to override a -L flag set in AM_LDFLAGS
> by just modifying LDFLAGS.

It is interesting that Automake decided to do this:

LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
        $(AM_LDFLAGS) $(LDFLAGS) -o $@

On one hand I can see that a project needs to take care to ensure that 
components it builds are used in the link.  On the other hand, I can 
see that the user needs a last resort way to influence the library 
search path.  This implies that a package developer should take great 
care to make sure that the content of AM_LDFLAGS will satisfy both 
objectives.

This is an autoconf/automake/package issue rather than a libtool 
issue.

> > I know that MPFR configure does work differently than almost any
> > other software package.
>
> I don't know what you mean here. The main difference IMHO, is that
> MPFR will try to get the compiler and flags chosen by GMP, but this

I stand corrected.  I was blaming the wrong package.  Sorry about 
that.  GMP is one of the few packages which may configure itself (by 
default) for a different architecture than the default architecture of 
the compiler or the architecture that the user requests via CFLAGS. 
It makes this decision based on which architecture offers the best 
performance rather than what the user needs.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/