GNU bug report logs - #7698
aclocal generates too strict a check for name-lister

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7698 in the body.
You can then email your comments to 7698 AT debbugs.gnu.org in the normal way.

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

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

From: Ximin Luo <infinity0 <at> gmx.com>
To: bug-automake <at> gnu.org
Subject: aclocal generates too strict a check for name-lister
Date: Tue, 21 Dec 2010 03:52:35 +0000

I have a core2 system, and have been trying to compile GMP 5.0.1 optimised for
other x86 CPUs, by doing (e.g.)

$ ./configure --host=pentium4-$(./config.guess | cut -d- -f2-)

However, these fail with an obscure error message about `link -dump -symbols`
(see snippet 1). After a convoluted path of debugging, I've worked out that the
cause is ./configure not detecting the presence of "/usr/bin/nm -B", in the
case where $build != $host.

The responsible code is the following snippet:
  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then

which occurs twice in GMP 5.0.1's ./configure, and once in aclocal.m4, so the
source seems to be automake's aclocal program. If you remove all occurrences of
the second test, the build works fine.

I have some test code at [1]. Note the WORKAROUND on line 232 - removing it
will cause builds such as

$ ./build-all-multi.sh pentium4

to fail when run on a core2.

I don't know much about how automake works, but it seems to me that the check
is too strict - nm shouldn't change with the CPU. If really necessary, maybe
only the last part of $build/$host could be matched instead?

Ximin

[1]
https://github.com/freenet/contrib-staging/blob/master/NativeBigInteger/build-all-multi.sh

----> snippet 1 <----

checking if globals are prefixed by underscore... link: invalid option -- 'd'
Try `link --help' for more information.
unknown
configure: WARNING: +----------------------------------------------------------
configure: WARNING: | Cannot determine global symbol prefix.
configure: WARNING: | link -dump -symbols output doesn't contain a global data
symbol.
configure: WARNING: | Will proceed with no underscore.
configure: WARNING: | If this is wrong then you'll get link errors referring
configure: WARNING: | to ___gmpn_add_n (note three underscores).
configure: WARNING: | In this case do a fresh build with an override,
configure: WARNING: |     ./configure gmp_cv_asm_underscore=yes
configure: WARNING: +----------------------------------------------------------
checking how to switch to read-only data section... 	.section	.rodata
checking for assembler .type directive... .type	$1,@$2
checking for assembler .size directive... .size	$1,$2
checking for assembler local label prefix... configure: WARNING: "link -dump
-symbols" failure
configure: WARNING: cannot determine local label, using default L
L
checking for assembler byte directive... .byte
checking how to define a 32-bit word... link: invalid option -- 'd'
Try `link --help' for more information.
link: invalid option -- 'd'
Try `link --help' for more information.
configure: error: cannot determine how to define a 32-bit word

Failed to configure for libjbigi-linux-pentium4; maybe it isn't supported on
your build environment.

Error building libjbigi-linux-pentium4!


-- 
GPG: 4096R/5FBBDBCE

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7698 <at> debbugs.gnu.org
Cc: Ximin Luo <infinity0 <at> gmx.com>
Subject: Re: bug#7698: aclocal generates too strict a check for name-lister
Date: Tue, 21 Dec 2010 14:36:02 +0100

Hello Ximin

[I hope this will work; I'm answering by cut & pasting from the
 debbugs web interface, since the bug report didn't make it to me
 through mail.]

> I have a core2 system, and have been trying to compile GMP 5.0.1
> optimised for other x86 CPUs, by doing (e.g.)
>  $ ./configure --host=pentium4-$(./config.guess | cut -d- -f2-)
>
> However, these fail with an obscure error message about `link -dump -symbols`
> (see snippet 1). After a convoluted path of debugging, I've worked out that
> the cause is ./configure not detecting the presence of "/usr/bin/nm -B", in
> the case where $build != $host.
>
> The responsible code is the following snippet:
>  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
>
> which occurs twice in GMP 5.0.1's ./configure, and once in aclocal.m4, so
> the source seems to be automake's aclocal program.
>
There's a misunderstanding here.  While aclocal indeed generates aclocal.m4,
it does so by copying macro definitions provided either by automake or by
third-parts packages.

To put it differently: aclocal's work is *not* to directly provide any
macro definition, but only to *retrieve* definitions of macros required
by configure.ac, and make such definitions available to autconf.  It
does so by copying those definition in aclocal.m4 (basically).  See the
automake manual for more information:
 <http://www.gnu.org/software/automake/manual/html_node/Invoking-aclocal.html>

The bug you're hitting must be located in a third-part macro, since no
automake-provided macro do something similar to that.  And in fact, it
seems to come from GMP-5.0.1's own acinclude.m4 (which is *not* the same
as aclocal.m4! see the automake manual for more info):

 $ cd /tmp/gmp-5.0.1
 $ grep -r '___gmpn_add_n (note three underscores)' .
 ./acinclude.m4:    AC_MSG_WARN([| to ___gmpn_add_n (note three underscores).])
 ./configure:    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: | to ___gmpn_add_n (note three underscores)." >&5
 ./configure:$as_echo "$as_me: WARNING: | to ___gmpn_add_n (note three underscores)." >&2;}

So you should report your issue to the GMP bug tracker.

For what concerns the automake bug tracker, I'm closing the bug
as invalid.

HTH,
   Stefano

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

From: Ximin Luo <infinity0 <at> gmx.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7698 <at> debbugs.gnu.org
Subject: Re: bug#7698: aclocal generates too strict a check for name-lister
Date: Tue, 21 Dec 2010 15:16:58 +0000

On 21/12/10 13:36, Stefano Lattarini wrote:
> The bug you're hitting must be located in a third-part macro, since no
> automake-provided macro do something similar to that.  And in fact, it
> seems to come from GMP-5.0.1's own acinclude.m4 (which is *not* the same
> as aclocal.m4! see the automake manual for more info):
> 
>  $ cd /tmp/gmp-5.0.1
>  $ grep -r '___gmpn_add_n (note three underscores)' .
>  ./acinclude.m4:    AC_MSG_WARN([| to ___gmpn_add_n (note three underscores).])
>  ./configure:    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: | to ___gmpn_add_n (note three underscores)." >&5
>  ./configure:$as_echo "$as_me: WARNING: | to ___gmpn_add_n (note three underscores)." >&2;}
> 
> So you should report your issue to the GMP bug tracker.
> 

Ah OK, thanks for the information. :) I'll explore this further and report it
to GMP.

Ximin

-- 
GPG: 4096R/5FBBDBCE

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

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Ximin Luo <infinity0 <at> gmx.com>, 7698 <at> debbugs.gnu.org
Subject: Re: bug#7698: aclocal generates too strict a check for name-lister
Date: Wed, 22 Dec 2010 01:55:59 +0100

Den 2010-12-21 14:36 skrev Stefano Lattarini:
> Hello Ximin
> 
> [I hope this will work; I'm answering by cut & pasting from the
>  debbugs web interface, since the bug report didn't make it to me
>  through mail.]
> 
>> I have a core2 system, and have been trying to compile GMP 5.0.1
>> optimised for other x86 CPUs, by doing (e.g.)
>>  $ ./configure --host=pentium4-$(./config.guess | cut -d- -f2-)
>>
>> However, these fail with an obscure error message about `link -dump -symbols`
>> (see snippet 1). After a convoluted path of debugging, I've worked out that
>> the cause is ./configure not detecting the presence of "/usr/bin/nm -B", in
>> the case where $build != $host.
>>
>> The responsible code is the following snippet:
>>  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
>>
>> which occurs twice in GMP 5.0.1's ./configure, and once in aclocal.m4, so
>> the source seems to be automake's aclocal program.
>>
> There's a misunderstanding here.  While aclocal indeed generates aclocal.m4,
> it does so by copying macro definitions provided either by automake or by
> third-parts packages.

FWIW, It smells exactly like a bug that was fixed in libtool 2.2.8 related
to this NEWS entry:

  - Fix 2.1b regression that caused nm to not be the default name lister.
    The regression affected mainly (arguably broken) cross compiles.

Cheers,
Peter

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

From: Ximin Luo <infinity0 <at> gmx.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 7698 <at> debbugs.gnu.org
Subject: Re: bug#7698: aclocal generates too strict a check for name-lister
Date: Wed, 22 Dec 2010 09:06:01 +0000

On 22/12/10 00:55, Peter Rosin wrote:
> FWIW, It smells exactly like a bug that was fixed in libtool 2.2.8 related
> to this NEWS entry:

I did some more poking around - this bug is in libtool, but not the one you
mention. The "responsible snippet" I pasted above is from libtool.m4, and it
exists in both 2.2.6 (what I have) and 2.2.10 (I checked the debian package
from experimental). I've sent a mail to bug-libtool <at> gnu.org.

X

-- 
GPG: 4096R/5FBBDBCE

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

From: Peter Rosin <peda <at> lysator.liu.se>
To: Ximin Luo <infinity0 <at> gmx.com>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 7698 <at> debbugs.gnu.org
Subject: Re: bug#7698: aclocal generates too strict a check for name-lister
Date: Wed, 22 Dec 2010 23:52:03 +0100

Den 2010-12-22 10:06 skrev Ximin Luo:
> On 22/12/10 00:55, Peter Rosin wrote:
>> FWIW, It smells exactly like a bug that was fixed in libtool 2.2.8 related
>> to this NEWS entry:
> 
> I did some more poking around - this bug is in libtool, but not the one you
> mention. The "responsible snippet" I pasted above is from libtool.m4, and it
> exists in both 2.2.6 (what I have) and 2.2.10 (I checked the debian package
> from experimental). I've sent a mail to bug-libtool <at> gnu.org.

Well, since I do not see any message on bug-libtool (yet), I'll respond here.

Your quoted "responsible snippet" is not really responsible, methinks.

The bug I mentioned was that when cross-compiling and yet expecting to find
a name lister that is not named as cross tools are normally named (i.e.
relying on 'nm' instead of 'pentium4-foo-bar-nm') libtool would go with the
'link' program instead of falling back to 'nm'. In the good old days, before
libtool could use 'link' (not the 'link' you have, another proprietary 'link')
to find symbols, libtool did fall back to 'nm' in setups such as yours,
and that regression was fixed in 2.2.8. This is exactly what seems to be
happening to you, so I can only encourage you to try with a more recent
libtool. Or, if you find it difficult to update libtool, install a
'pentium4-foo-bar-nm' where your current libtool will find it, perhaps as a
symlink to '/usr/bin/nm'.

Cheers,
Peter

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

From: Ximin Luo <infinity0 <at> gmx.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 7698 <at> debbugs.gnu.org
Subject: Re: bug#7698: aclocal generates too strict a check for name-lister
Date: Sat, 25 Dec 2010 14:09:25 +0000

On 22/12/10 22:52, Peter Rosin wrote:
> Well, since I do not see any message on bug-libtool (yet), I'll respond here.
> 
> Your quoted "responsible snippet" is not really responsible, methinks.
> 
> The bug I mentioned was that when cross-compiling and yet expecting to find
> a name lister that is not named as cross tools are normally named (i.e.
> relying on 'nm' instead of 'pentium4-foo-bar-nm') libtool would go with the
> 'link' program instead of falling back to 'nm'. In the good old days, before
> libtool could use 'link' (not the 'link' you have, another proprietary 'link')
> to find symbols, libtool did fall back to 'nm' in setups such as yours,
> and that regression was fixed in 2.2.8. This is exactly what seems to be
> happening to you, so I can only encourage you to try with a more recent
> libtool. Or, if you find it difficult to update libtool, install a
> 'pentium4-foo-bar-nm' where your current libtool will find it, perhaps as a
> symlink to '/usr/bin/nm'.
> 
> Cheers,
> Peter

The full snippet (libtool.m4) is:

  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
    lt_nm_to_check="$lt_nm_to_check nm"
  fi

This fails for e.g. { build=i686-pc-linux-gnu host=i486-pc-linux-gnu }, or {
build=core2-pc-linux-gnu host=athlon64-pc-linux-gnu }, but this is too strict
and unnecessary, because they still use the same object file format.

(I'm not an expert in this area, so I may be wrong here, but from what I know,
I believe I'm right.)

(This is still true for libtool 2.2.10. The commit you made, `git show
032d3cc9c17b51649153f51c50d1586774799cbd`, aims to work around it in another
way, but I think my suggestion is a more "direct" fix to the problem.)

X

-- 
GPG: 4096R/5FBBDBCE

Previous Next

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