GNU bug report logs - #9728
Incorrect -L flags order for HP-UX

Previous Next

To reply to this bug, email your comments to 9728 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-libtool <at> gnu.org
Subject: Incorrect -L flags order for HP-UX
Date: Tue, 11 Oct 2011 15:58:30 +0200

With libtool 2.4 and automake 1.11.1, we have the following problem
for MPFR 3.1.0. We have received a bug report saying that when the
tests are run on a HP-UX machine, the following command is run:

libtool: link: gcc -O2 -s -o tversion tversion.o  -L/opt/gnu/lib ./.libs/libfrtests.a -lm -L../src/.libs -lmpfr -lgmp -Wl,+b -Wl,/xxx/gnu/mpfr-3.1.0/objdir/src/.libs:/opt/gnu/lib

The problem is that -L../src/.libs comes after -L/opt/gnu/lib, so that
linking is done against the MPFR version installed in /opt/gnu/lib
instead of the one from ../src/.libs, which has just been compiled.

-L/opt/gnu/lib comes from LDFLAGS (set up by the configure script);
it is needed to find some other library (GMP). -L../src/.libs is
added to find the MPFR library to be tested (it is necessary under
HP-UX). It seems to be added to $LIBS, where in tests/Makefile.in,
one gets:

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

tversion$(EXEEXT): $(tversion_OBJECTS) $(tversion_DEPENDENCIES)
        @rm -f tversion$(EXEEXT)
        $(LINK) $(tversion_OBJECTS) $(tversion_LDADD) $(LIBS)

Note: the problem cannot be reproduced under Linux, as
../src/.libs/libmpfr.so is used instead of -L... -lmpfr.

Thread of the bug report:
  http://websympa.loria.fr/wwsympa/arc/mpfr/2011-10/msg00042.html

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Vincent Lefevre <vincent <at> vinc17.net>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Wed, 12 Oct 2011 21:52:36 -0500

On 10/11/2011 08:58 AM, Vincent Lefevre wrote:
> With libtool 2.4 and automake 1.11.1, we have the following problem
> for MPFR 3.1.0. We have received a bug report saying that when the
> tests are run on a HP-UX machine, the following command is run:
>
> libtool: link: gcc -O2 -s -o tversion tversion.o  -L/opt/gnu/lib ./.libs/libfrtests.a -lm -L../src/.libs -lmpfr -lgmp -Wl,+b -Wl,/xxx/gnu/mpfr-3.1.0/objdir/src/.libs:/opt/gnu/lib
>
> The problem is that -L../src/.libs comes after -L/opt/gnu/lib, so that
> linking is done against the MPFR version installed in /opt/gnu/lib
> instead of the one from ../src/.libs, which has just been compiled.

Hi Vincent,

Unfortunately this is a fairly common problem.

If the flags were added by the user, they could set LIBS=-L/opt/gnu/lib 
instead on some platfroms, but that won't work on HP-UX either because 
its linker is rather strict that -L flags for paths that contain the 
library be ordered before the -l flag for that library.

Anyway, the problem can be avoided by not putting the -L and -l flags 
for gmp in LDFLAGS and LIBS, instead put both in e.g. GMP_LIBS, 
(GMP_LIBS="-L/opt/gnu/lib -lgmp"), then add $(GMP_LIBS) to LDADD.

Peter

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Thu, 13 Oct 2011 11:26:56 +0200

Hi Peter,

On 2011-10-12 21:52:36 -0500, Peter O'Gorman wrote:
> Unfortunately this is a fairly common problem.

Will this eventually be fixed? For instance libtool/automake could
put the -Lrelative/path in a variable that would appear before
$(LDFLAGS).

Otherwise the autoconf manual should be corrected, as it currently
says to use LDFLAGS for -L options.

> If the flags were added by the user, they could set LIBS=-L/opt/gnu/lib
> instead on some platfroms, but that won't work on HP-UX either because its
> linker is rather strict that -L flags for paths that contain the library be
> ordered before the -l flag for that library.
> 
> Anyway, the problem can be avoided by not putting the -L and -l flags for
> gmp in LDFLAGS and LIBS, instead put both in e.g. GMP_LIBS,
> (GMP_LIBS="-L/opt/gnu/lib -lgmp"), then add $(GMP_LIBS) to LDADD.

OK, I'll try that.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Thu, 13 Oct 2011 12:32:00 +0200

On 2011-10-12 21:52:36 -0500, Peter O'Gorman wrote:
> If the flags were added by the user, they could set LIBS=-L/opt/gnu/lib
> instead on some platfroms, but that won't work on HP-UX either because its
> linker is rather strict that -L flags for paths that contain the library be
> ordered before the -l flag for that library.
> 
> Anyway, the problem can be avoided by not putting the -L and -l flags for
> gmp in LDFLAGS and LIBS, instead put both in e.g. GMP_LIBS,
> (GMP_LIBS="-L/opt/gnu/lib -lgmp"), then add $(GMP_LIBS) to LDADD.

This doesn't work with autoconf's AC_CHECK_LIB and other tests.
And using LDFLAGS for autoconf and LDADD in the Makefile would
be quite hard to maintain due to the risk of inconsistencies.

autoconf and libtool should agree on the way to add -L flags.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Vincent Lefevre <vincent <at> vinc17.net>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Thu, 13 Oct 2011 09:06:22 -0500

[Message part 1 (text/plain, inline)]

On 10/13/2011 05:32 AM, Vincent Lefevre wrote:
> On 2011-10-12 21:52:36 -0500, Peter O'Gorman wrote:
>> If the flags were added by the user, they could set LIBS=-L/opt/gnu/lib
>> instead on some platfroms, but that won't work on HP-UX either because its
>> linker is rather strict that -L flags for paths that contain the library be
>> ordered before the -l flag for that library.
>>
>> Anyway, the problem can be avoided by not putting the -L and -l flags for
>> gmp in LDFLAGS and LIBS, instead put both in e.g. GMP_LIBS,
>> (GMP_LIBS="-L/opt/gnu/lib -lgmp"), then add $(GMP_LIBS) to LDADD.
>
> This doesn't work with autoconf's AC_CHECK_LIB and other tests.
> And using LDFLAGS for autoconf and LDADD in the Makefile would
> be quite hard to maintain due to the risk of inconsistencies.
>
> autoconf and libtool should agree on the way to add -L flags.
>

Hi Vincent,

Well, if this is a bug at all, it is an automake/autoconf one, libtool 
does not set the order of flags in Makefile.in, but I don't believe that 
it is a bug.

LDFLAGS, CFLAGS, etc are for the user to set. It should be possible for 
the user to build a package doing ./configure ..options..; make 
LDFLAGS=-fancyflag CPPFLAGS=-I/want/coffee;

http://www.gnu.org/prep/standards/standards.html#Command-Variables

The usual way to get specific flags set to allow this is to save 
LDFLAGS, CPPFLAGS etc. before doing an autoconf test, do the test, then 
restore the original flags.

Something like the attached patch should work for mpfr.

Peter

[mpfr.diff (text/x-patch, attachment)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Fri, 14 Oct 2011 01:06:29 +0200

Hi,

On 2011-10-13 09:06:22 -0500, Peter O'Gorman wrote:
> Well, if this is a bug at all, it is an automake/autoconf one,
> libtool does not set the order of flags in Makefile.in, but I don't
> believe that it is a bug.

The autoconf manual says to use LDFLAGS for the -L options. So, it
is either a bug in the autoconf manual or in automake.

> LDFLAGS, CFLAGS, etc are for the user to set.

And this is what MPFR does with --with-gmp, which is a shorthand
for updating CPPFLAGS and LDFLAGS.

> It should be possible for the user to build a package doing
> ./configure ..options..; make LDFLAGS=-fancyflag
> CPPFLAGS=-I/want/coffee;

I don't think this should be allowed: MPFR does some tests at
configure time based on the current environment. If the user
modifies the environment at make time, the configure tests no
longer make sense (e.g. modifying LDFLAGS at make time can select
a different GMP version). So, if the user does this, it is up to
him to make sure that the changes are equivalent to what was set
at configure time.

> Something like the attached patch should work for mpfr.

There are several problems with it. First, I assume that LOADLIBES
should contain $(AM_CPPFLAGS) too. But the main problem is the
inconsistent flags order: in the compile command, $(AM_CPPFLAGS)
appears before $(CPPFLAGS), while in the link command, $(GMP_LIBS)
appears after $(LDFLAGS). This means that if the user uses both
--with-gmp and CPPFLAGS/LDFLAGS to provide search directories,
the include and library search paths will be inconsistent.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Vincent Lefevre <vincent <at> vinc17.net>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Thu, 13 Oct 2011 18:21:35 -0500

On 10/13/2011 06:06 PM, Vincent Lefevre wrote:

>
>> Something like the attached patch should work for mpfr.
>
> There are several problems with it. First, I assume that LOADLIBES
> should contain $(AM_CPPFLAGS) too. But the main problem is the
> inconsistent flags order: in the compile command, $(AM_CPPFLAGS)
> appears before $(CPPFLAGS), while in the link command, $(GMP_LIBS)
> appears after $(LDFLAGS). This means that if the user uses both
> --with-gmp and CPPFLAGS/LDFLAGS to provide search directories,
> the include and library search paths will be inconsistent.
>

Ok, this is not a libtool bug though. When it can libtool will add the 
path to the .so instead of -L -l for libraries in the build dir. On many 
systems this works, but HP-UX is one of those systems where it does not, 
so -L -l are used instead. This can cause problems when an older version 
of the library is installed in $prefix.

Sorry that I can't help more.

Thanks,
Peter

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Fri, 14 Oct 2011 01:43:19 +0200

On 2011-10-13 18:21:35 -0500, Peter O'Gorman wrote:
> Ok, this is not a libtool bug though. When it can libtool will add the path
> to the .so instead of -L -l for libraries in the build dir. On many systems
> this works, but HP-UX is one of those systems where it does not, so -L -l
> are used instead. This can cause problems when an older version of the
> library is installed in $prefix.

Which tool is responsible for adding the -L with the relative path?

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Fri, 14 Oct 2011 01:54:51 +0200

On 2011-10-13 18:21:35 -0500, Peter O'Gorman wrote:
> Ok, this is not a libtool bug though. When it can libtool will add the path
> to the .so instead of -L -l for libraries in the build dir. On many systems
> this works, but HP-UX is one of those systems where it does not, so -L -l
> are used instead. This can cause problems when an older version of the
> library is installed in $prefix.

Or perhaps the -L shouldn't be added at all automatically, but should
be specified in the Makefile.am file?

For instance, should -L$(top_builddir)/src/.libs be added to AM_LDFLAGS
in tests/Makefile.am?

Since $(AM_LDFLAGS) appears before $(LDFLAGS) in the LINK command,
this should solve the problem. This -L flag would then be used also
on systems that don't need it, but I don't think this is a problem.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Vincent Lefevre <vincent <at> vinc17.net>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Thu, 13 Oct 2011 20:48:45 -0500

On 10/13/2011 06:54 PM, Vincent Lefevre wrote:
> On 2011-10-13 18:21:35 -0500, Peter O'Gorman wrote:
>> Ok, this is not a libtool bug though. When it can libtool will add the path
>> to the .so instead of -L -l for libraries in the build dir. On many systems
>> this works, but HP-UX is one of those systems where it does not, so -L -l
>> are used instead. This can cause problems when an older version of the
>> library is installed in $prefix.
>
> Or perhaps the -L shouldn't be added at all automatically, but should
> be specified in the Makefile.am file?
>
> For instance, should -L$(top_builddir)/src/.libs be added to AM_LDFLAGS
> in tests/Makefile.am?
>
> Since $(AM_LDFLAGS) appears before $(LDFLAGS) in the LINK command,
> this should solve the problem. This -L flag would then be used also
> on systems that don't need it, but I don't think this is a problem.
>

That might work.

Peter

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 9728 <at> debbugs.gnu.org, Peter O'Gorman <peter <at> pogma.com>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Thu, 13 Oct 2011 21:39:56 -0500 (CDT)

On Fri, 14 Oct 2011, Vincent Lefevre wrote:
>> It should be possible for the user to build a package doing
>> ./configure ..options..; make LDFLAGS=-fancyflag
>> CPPFLAGS=-I/want/coffee;
>
> I don't think this should be allowed: MPFR does some tests at
> configure time based on the current environment. If the user
> modifies the environment at make time, the configure tests no
> longer make sense (e.g. modifying LDFLAGS at make time can select
> a different GMP version). So, if the user does this, it is up to

Actually, the user should be allowed to shoot themselves in the foot 
if they request it.  LDFLAGS should be set including the user-provided 
setting during the entire configure run so test results should be 
valid.  I know that MPFR configure does work differently than almost 
any other software package.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 9728 <at> debbugs.gnu.org, Peter O'Gorman <peter <at> pogma.com>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Fri, 14 Oct 2011 09:40:44 +0200

On 2011-10-13 21:39:56 -0500, Bob Friesenhahn wrote:
> On Fri, 14 Oct 2011, Vincent Lefevre wrote:
> >>It should be possible for the user to build a package doing
> >>./configure ..options..; make LDFLAGS=-fancyflag
> >>CPPFLAGS=-I/want/coffee;
> >
> >I don't think this should be allowed: MPFR does some tests at
> >configure time based on the current environment. If the user
> >modifies the environment at make time, the configure tests no
> >longer make sense (e.g. modifying LDFLAGS at make time can select
> >a different GMP version). So, if the user does this, it is up to
> 
> 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.

Note: Mutt also modifies CPPFLAGS / LDFLAGS, not the AM_* versions.

> LDFLAGS should be set including the user-provided setting
> during the entire configure run so test results should be valid.

This is how this works with MPFR.

> 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
is necessary in general (we have much fewer bug reports since we do
this), though quite awkward. And if GMP does something in the user's
back, MPFR shouldn't be blame for trying to fix things.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 9728 <at> debbugs.gnu.org, Peter O'Gorman <peter <at> pogma.com>, bug-libtool <at> gnu.org
Subject: Re: bug#9728: Incorrect -L flags order for HP-UX
Date: Fri, 14 Oct 2011 08:52:45 -0500 (CDT)

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
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.