[bug] LIBS variable not correct for linking static libraries when building with autoconf tools

[jngrb]

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 20.04
• Compiler+version: gcc-9
• Conan version: conan 1.47.0
• Python version: Python 3.8.10

Steps to reproduce (Include if Applicable)

1. create a dummy conanfile.py for wrapping a static library, e.g. to wrap /usr/lib/x86_64-linux-gnu/libcrypto.a, use this package_info method:

  def package_info(self):
    self.cpp_info.libdirs = ["/usr/lib/x86_64-linux-gnu"]
    self.cpp_info.libs = ["libcrypto.a"]

2. have a second recipe that consumes the dummy recipe and builds a executable or library with autotools. Excerpts from such a conanfile.py:

from conans import ConanFile, AutoToolsBuildEnvironment
[...]
  def build(self)
    [...]
    autotools = AutoToolsBuildEnvironment(self, win_bash=tools.os_info.is_windows)
    configure_args = [...]
    autotools.configure(vars=self._autotools_vars, args=configure_args)
    [...]

Actual behaviour

autotools / configure is called with environment variable

LIBS=-llibcrypto.a

Expected behaviour

autotools / configure is called with environment variable

LIBS=-l:libcrypto.a

References:

• see https://stackoverflow.com/questions/6578484/telling-gcc-directly-to-link-a-library-statically
• and https://sourceware.org/binutils/docs/ld/Options.html

-l namespec: [...] If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a [or _libnamespec.so].

Logs (Executed commands with output) (Include/Attach if Applicable)

I found the relevant python methods to be these:

• conans/client/build/compiler_flags.py#L244
• conan/tools/gnu/gnudeps_flags.py#L73

[memsharded]

Hi @jngrb

First, a note of warning, about the AutotoolsBuildEnvironment. It is legacy, and it has already been removed from Conan 2.0. Unless it is a regression or something very serious, reports and feature requests should be directed to integrations under from conan.tools.gnu in this case.

Then, I would like to understand better the error mode. How is it failing, is it not linking? What is the error message?

I am also concerned that this is only for ld linker, users using other linkers will fail if we add this, and there is no model for defining the linker so far.

[jngrb]

Hi @memsharded

I understand your points. In one of my use cases, I want to build libcurl instead of a openssl conan package from conan-center-index with the openssl from the native distribution. When I attempt to do this using a dummy recipe (the static linking case is outlined above), I get for the attempt with a static openssl from the system (in the build step for libcurl):

configure: error: in `/home/<user>/.conan/data/libcurl/7.80.0/_/_/build/<hash>/source_subfolder':
configure: error: C compiler cannot create executables
See `config.log' for more details

excerpt from config.log:

configure:4878: checking whether the C compiler works
configure:4900: gcc-9 -m64 -g -fPIC -I/home/<user>/.conan/data/libtool/2.4.6/_/_/package/<hash>/include -I/home/<user>/.conan/data/openssl/system/_/_/package/<hash>/include -I/ -I/ -I/home/<user>/.conan/data/zlib/1.2.12/_/_/package/<hash>/include -m64 -L/home/<user>/.conan/data/libtool/2.4.6/_/_/package/<hash>/lib -L/home/<user>/.conan/data/zlib/1.2.12/_/_/package/<hash>/lib conftest.c -lltdl -llibssl.a -llibcrypto.a -lz -ldl -lpthread -lrt >&5
/usr/bin/ld: cannot find -llibssl.a
/usr/bin/ld: cannot find -llibcrypto.a
collect2: error: ld returned 1 exit status
configure:4904: $? = 1
configure:4944: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "curl"
| #define PACKAGE_TARNAME "curl"
| #define PACKAGE_VERSION "-"
| #define PACKAGE_STRING "curl -"
| #define PACKAGE_BUGREPORT "a suitable curl mailing list: https://curl.se/mail/"
| #define PACKAGE_URL ""
| #define DEBUGBUILD 1
| #define CURLDEBUG 1
| /* end confdefs.h.  */
| 
| int main (void)
| {
| 
|  ;
|  return 0;
| }
configure:4949: error: in `/home/<user>/.conan/data/libcurl/7.80.0/_/_/build/<hash>/source_subfolder':
configure:4951: error: C compiler cannot create executables
See `config.log' for more details

When I replace -llibssl.a -llibcrypto.a with -l:libssl.a -l:libcrypto.a in

gcc-9 -m64 -g -fPIC -I/home/<user>/.conan/data/libtool/2.4.6/_/_/package/<hash>/include -I/home/<user>/.conan/data/openssl/system/_/_/package/<hash>/include -I/ -I/ -I/home/<user>/.conan/data/zlib/1.2.12/_/_/package/<hash>/include -m64 -L/home/<user>/.conan/data/libtool/2.4.6/_/_/package/<hash>/lib -L/home/<user>/.conan/data/zlib/1.2.12/_/_/package/<hash>/lib conftest.c -lltdl -llibssl.a -llibcrypto.a -lz -ldl -lpthread -lrt

I can compile the conftest.c as quoted in the logs above.

--

I think that both AutoToolsBuildEnvironment and conan.tools.gnu are affected as both source lines that I quoted are basically identical:

• conans/client/build/compiler_flags.py#L244 => AutoToolsBuildEnvironment
• conan/tools/gnu/gnudeps_flags.py#L73 => conan.tools.gnu

Thus, a potential fix could be applied to both methods.

[jngrb]

In PR #11713 , I provide a work-in-progress fix that works for my use cases.

I uploaded the PR for documentation, but leave it in WIP state, i.e. don't want it to be merged until the solution for this issue here is discussed thoroughly.