mainGNU Libtool - Support: sr #110261, _LT_CMD_OLD_ARCHIVE should not...

 
 

sr #110261: _LT_CMD_OLD_ARCHIVE should not inline AC_PROG_RANLIB

Submitter:  Zack Weinberg <zackw>
Submitted:  Fri 10 Jul 2020 06:54:50 PM UTC
Votes: 5
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 17 Jan 2024 07:24:42 AM UTC, comment #1: 

LT_INIT already does AC_PREREQ(2.62), so relying on AC_PROG_RANLIB sounds fine

want to send a patch to the mailing list ?

Mike Frysinger <vapier>
Group Member
Fri 10 Jul 2020 06:54:50 PM UTC, original submission:  

Autoconf bug #108503 reports a conflict between the advice given by libtoolize and the advice given by autoscan:

> Let's say that, in an empty directory, I have a configure.ac file
> that looks like this:
>
>   AC_INIT([testcase])
>   LT_INIT
>   AC_OUTPUT
>
>
> Then I autoreconf, which puts ltmain.sh into the current
> directory. Now when I run autoscan, it produces the following
> warnings:
>
>
>   Local-Admins-MacBook-Pro:autoconf_bug_reports_dir localadmin$ autoscan
>   configure.ac: warning: missing AC_PROG_CXX wanted by: ltmain.sh:960
>   configure.ac: warning: missing AC_PROG_INSTALL wanted by: ltmain.sh:1028
>   configure.ac: warning: missing AC_PROG_MAKE_SET wanted by: ltmain.sh:2163
>   configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:2455
>
>
> So I add these macros to my configure.ac, and now, when I autoreconf
> again, it includes this warning:
>
>
>   glibtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
>
>
> If I then go and remove AC_PROG_RANLIB, autoscan will then warn
> about it being missing again the next time I run it, leading to an
> endless cycle of conflicting warnings.


This is happening because _LT_CMD_OLD_ARCHIVE (invoked by LT_INIT) inlines the body of AC_PROG_RANLIB, so autoscan does not know that $RANLIB will be set.  If _LT_CMD_OLD_ARCHIVE were to AC_REQUIRE([AC_PROG_RANLIB]) instead of embedding AC_CHECK_TOOL([RANLIB], [ranlib], [:]), there would be no problem.

AC_PROG_RANLIB has used AC_CHECK_TOOL since the beginning of the VCS history for Autoconf (in 2001), so if this is a workaround for a very old autoconf that used AC_CHECK_PROG instead of AC_CHECK_TOOL, I don't think it's necessary any more

Zack Weinberg <zackw>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by vapier (Posted a comment)
  • -email is unavailable- added by egallager (Voted in favor of this item)
  • -email is unavailable- added by egallager (had originally opened this bug with autoconf)
  • -email is unavailable- added by zackw (Submitted the item)
  •  

    There are 5 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-05 egallager Carbon-Copy- Added egallager
    2020-07-10 egallager Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code