[sr #110261] _LT_CMD_OLD_ARCHIVE should not inline AC_PROG_RANLIB

[Zack Weinberg]

URL:
  

 Summary: _LT_CMD_OLD_ARCHIVE should not inline AC_PROG_RANLIB
 Project: GNU Libtool
Submitted by: zackw
Submitted on: Fri 10 Jul 2020 06:54:50 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

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




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: Can't make dll out of a static convenience library: This system cannot link to static lib

[Bob Friesenhahn]

On Sat, 4 Jul 2020, basini...@gmail.com wrote:


Hi. I'm trying to build mingw-w64-gnutls 3.6.12 on Archlinux. At some point it 
wants to make a C++ dll out of a C convenience static library and a C++ object 
file, but libtool omits the static library and link fails with undefined 
reference.
I don't understand why libtool omits the static library, because if I call g++ 
directly the dll is created just fine. I had to manually add `-lssp` to the 
command line, but I'm not sure if that's the cause.


Libtool assumes that static libraries do not contain objects which are 
built appropriately for use in shared libraries or DLLs.  Quite often 
objects need to be built in special ways (e.g -fPIC, 
dllexport/dllimport declarations) in order to work in shared 
libraries.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt