GNU bug report logs - #80155
Linker path does not have real file for library -lLIB

Previous Next

To reply to this bug, email your comments to 80155 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: Kirill Makurin <maiddaisuki <at> outlook.com>
To: "bug-libtool <at> gnu.org" <bug-libtool <at> gnu.org>
Subject: Linker path does not have real file for library -lLIB
Date: Thu, 8 Jan 2026 17:24:16 +0000

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

Hello,

I want to address very annoying libtool behavior which I had to encounter countless times when building stuff with MSVC.

Here's an example:

```
libtool: warning: Linker path does not have real file for library -lwldap32.
libtool: warning: I have the capability to make that library automatically link in when
libtool: warning: you link to this library.  But I can only do this if you have a
libtool: warning: shared version of the library, which you do not appear to have
libtool: warning: because I did check the linker path looking for a file starting
libtool: warning: with wldap32 and none of the candidates passed a file format test
libtool: warning: using a file magic. Last file checked: /cygdrive/c/WINDOWS/system32/secur32.dll
libtool: warning: Linker path does not have real file for library -liphlpapi.
libtool: warning: I have the capability to make that library automatically link in when
libtool: warning: you link to this library.  But I can only do this if you have a
libtool: warning: shared version of the library, which you do not appear to have
libtool: warning: because I did check the linker path looking for a file starting
libtool: warning: with iphlpapi and none of the candidates passed a file format test
libtool: warning: using a file magic. Last file checked: /cygdrive/c/PROGRA~2/WI3CF2~1/10/lib/100261~1.0/um/x64/iphlpapi.lib
```

Here, libtool failed to find *real library files* for -lwldap32 and -liphlpapi.
Those are system libraries installed in C:\Windows\System32:

```
$ which wldap32.dll
/c/Windows/System32/wldap32.dll
$ file /c/Windows/System32/wldap32.dll
/c/Windows/System32/wldap32.dll: PE32+ executable for MS Windows 10.00 (DLL), x86-64, 8 sections
$ which iphlpapi.dll
/c/Windows/System32/iphlpapi.dll
$ file /c/Windows/System32/iphlpapi.dll
/c/Windows/System32/iphlpapi.dll: PE32+ executable for MS Windows 10.00 (DLL), x86-64, 8 sections
```

The worst part of this behavior is that instead of failing, libtool proceeds creating *static* library. This is nonsense on Windows. This *static* library very likely contains symbol names mangled with __declspec(dllexport) and it will not work as static library.

If you're lucky, your build will just fail, but there are cases when such *static* library may get installed and will cause subsequent builds which want to use it to fail. I have encountered it and it was frustrating.

This issue also is very likely to occur when using libraries build by cmake, since sometimes they are prefixed with "lib", e.g. libfoo.dll. Real examples are libxml2.dll and libcurl.dll. I probably need to address naming convention mess with MSVC in another bug report.

I propose that libtool should proceed creating DLL in such cases, asumming DLL is somewhere in PATH and issuing a warning massage saying something like "failed to locale DLL for -lLIB. Executables using this DLL may fail to run."

My point here is that in vast majority of cases you use libtool with Autotools and have already checked during configuration whether library links, and for native builds whether it is actually usable.

Another case when this issue may occur is when names of import library and the DLL are different on purpose. For example, winpthreads install two import libraries pthread[.dll].lib and winpthread[.dll].lib, both linking to winpthread-1.dll. Using pthread.lib is impossible with libtool, unless you create a link or a copy named pthread*.dll.

- Kirill Makurin

[Message part 2 (text/html, inline)]

Previous Next

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