GNU bug report logs - #54421
AM_PROG_AR and LT_INIT don't work together when using lib.exe

Previous Next

To reply to this bug, email your comments to 54421 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: Tim Ruffing <crypto <at> timruffing.de>
To: bug-automake <at> gnu.org
Subject: AM_PROG_AR and LT_INIT don't work together when using lib.exe
Date: Wed, 16 Mar 2022 15:24:37 +0100

Hello :)

Assume environment variable AR="lib.exe" and configure.ac has

```
AM_PROG_AR
LT_INIT
```

Then AM_PROG_AR checks for an archiver using AC_CHECK_TOOLS. Then it
detects the lib.exe interface and prefixes the AR variable with a call
to ar-lib. (There's a FIXME in the code that says that overwriting is
wrong). But so far so good, this works.

Now LT_INIT will again look for an archiver using AC_CHECK_TOOLS (in
subroutine _LT_PROG_AR). The check will discover that ac_cv_prog_AR has
"lib.exe" (unprefixed!) and overwrites AR with it.

So AR is correct (with ar-lib prefix) after AM_PROG_AR but LT_INIT
overwrites with the unprefixed value again, causing the build the fail.
I wonder why noone has reported this so far. I tend to think that
lib.exe support is only really useful in combination with libtool but
this then triggers the bug.

Possible workarounds include:
 * Calling AM_PROG_AR after LT_INIT. But this will raise a warning in
   autoreconf telling me that I should call AM_PROG_AR before LT_INIT.
 * Clearing the cache value. This is what I've done for now in our
   project [1]. Note that here I'm careful and clear two cache
   variables but in in the end it's enough to clear ac_cv_prog_AR.

The aforementioned FIXME mentions introducing am_AR as a cleaner way.
This sounds like it fix the problem but maybe I'm overlooking
something. A crude hack is to overwrite not only AR but also
ac_cv_prog_AR.

Best,
Tim

[1] https://github.com/bitcoin-core/secp256k1/pull/1084/commits/e6b8a1ca47c07b798cf45ea85e257546c4dbafc4

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: 54421 <at> debbugs.gnu.org, bug-automake <at> gnu.org
Subject: Re: AM_PROG_AR and LT_INIT don't work together when using lib.exe
Date: Fri, 13 Jan 2023 05:52:47 +0000 (UTC)

On Wed, 16 Mar 2022 15:24:37 +0100, Tim Ruffing wrote:
> Assume environment variable AR="lib.exe" and configure.ac has
>
> ```
> AM_PROG_AR
> LT_INIT
> ```

i think the expectation is that, if you're using libtool, then you
use libtool.  it can create static convenience libraries too:
https://www.gnu.org/software/libtool/manual/html_node/Static-libraries.html
-mike

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

From: Tim Ruffing <crypto <at> timruffing.de>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: 54421 <at> debbugs.gnu.org, bug-automake <at> gnu.org
Subject: Re: AM_PROG_AR and LT_INIT don't work together when using lib.exe
Date: Fri, 13 Jan 2023 13:52:14 +0100

On Fri, 2023-01-13 at 05:52 +0000, Mike Frysinger wrote:
> i think the expectation is that, if you're using libtool, then you
> use libtool.  

Well, I *use* libtool. libtool needs some AR. I choose to use
libtool.exe with the ar-lib wrapper. 

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: 54421 <at> debbugs.gnu.org
Subject: Re: AM_PROG_AR and LT_INIT don't work together when using lib.exe
Date: Sat, 14 Jan 2023 00:03:51 -0500

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

On 13 Jan 2023 13:52, Tim Ruffing wrote:
> On Fri, 2023-01-13 at 05:52 +0000, Mike Frysinger wrote:
> > i think the expectation is that, if you're using libtool, then you
> > use libtool.  
> 
> Well, I *use* libtool. libtool needs some AR. I choose to use
> libtool.exe with the ar-lib wrapper. 

you wondered why no one has reported/noticed hits before.  i gave you
an explanation.  what you're doing is unusual, and so far, i haven't
seen an explanation as to why you're doing something unusual.  so the
(implicit) question still stands: why are you using Automake's archive
(ar-lib) logic when libtool already provides support for doing the same
thing -- creating static archives.

should we fix it ?  probably.  is it worth the effort ?  maybe not.
would we accept patches from someone who wants to spend the time ?
depends on the patch.
-mike

[signature.asc (application/pgp-signature, inline)]

Previous Next

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