bug#80155: Linker path does not have real file for library -lLIB
Kirill Makurin <[email protected]> Sat, 14 Feb 2026 18:00:47 +0000
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <LV5PR05MB998298C1DF40453851A9A0C073B16EA@LV5PR05MB998298.namprd05.prod.outlook.com> |
--_000_LV5PR05MB998298C1DF40453851A9A0C073B16EALV5PR05MB998298_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Ileana,
Ileana Dumitrescu wrote:
> On 08/01/2026 19:24, Kirill Makurin wrote:
>> I want to address very annoying libtool behavior which I had to
>> encounter countless times when building stuff with MSVC.
>>
>> 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 frustrati=
ng.
>>
>> 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.
>
> I think this could be updated, but the error message should inform users
> of how to generate static libraries should this change have unintended
> results for other users. If you submit a patch for this, I would be
> happy to apply it :)
This will require me to study ltmain.sh (or whatever it is generated from) =
more closely, which will surely take me some time, but I hope I will find t=
ime to do this. Though, I can't promise it'll be soon.
With the current state of things, it is really hard to make use of dependen=
cies built with different build systems (autotools/meson/cmake) when using =
MSVC, and this is really frustrating. I manage to workaround these issues m=
ost of the time, but this must be really frustrating for most of the users =
when simple things like linking against some dependency does not work.
I hope we can improve this situation over time to make using MSVC more user=
friendly.
- Kirill Makurin
--_000_LV5PR05MB998298C1DF40453851A9A0C073B16EALV5PR05MB998298_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);">Hi </span><span style=3D"color: rgb(0,=
0, 0);" class=3D"elementToProof">Ileana,</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0);">Ileana Dumitrescu wrote:</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);">> On 08/01/2026 19:24, Kirill Makur=
in wrote:<br>
>> I want to address very annoying libtool behavior which I had to<br=
>
>> encounter countless times when building stuff with MSVC.<br>
>><br>
>> The worst part of this behavior is that instead of failing, libtoo=
l<br>
>> proceeds creating *static* library. This is nonsense on Windows. T=
his<br>
>> *static* library very likely contains symbol names mangled with<br=
>
>> __declspec(dllexport) and it will not work as static library.<br>
>><br>
>> If you're lucky, your build will just fail, but there are cases wh=
en<br>
>> such *static* library may get installed and will cause subsequent =
builds<br>
>> which want to use it to fail. I have encountered it and it was fru=
strating.<br>
>><br>
>> This issue also is very likely to occur when using libraries build=
by<br>
>> cmake, since sometimes they are prefixed with "lib", e.g=
. libfoo.dll.<br>
>> Real examples are libxml2.dll and libcurl.dll. I probably need to<=
br>
>> address naming convention mess with MSVC in another bug report.<br=
>
>><br>
>> I propose that libtool should proceed creating DLL in such cases,<=
br>
>> asumming DLL is somewhere in PATH and issuing a warning massage sa=
ying<br>
>> something like "failed to locale DLL for -lLIB. Executables u=
sing this<br>
>> DLL may fail to run."<br>
>><br>
>> My point here is that in vast majority of cases you use libtool wi=
th<br>
>> Autotools and have already checked during configuration whether li=
brary<br>
>> links, and for native builds whether it is actually usable.<br>
>><br>
>> Another case when this issue may occur is when names of import lib=
rary<br>
>> and the DLL are different on purpose. For example, winpthreads ins=
tall<br>
>> two import libraries pthread[.dll].lib and winpthread[.dll].lib, b=
oth<br>
>> linking to winpthread-1.dll. Using pthread.lib is impossible with<=
br>
>> libtool, unless you create a link or a copy named pthread*.dll.<br=
>
><br>
> I think this could be updated, but the error message should inform use=
rs<br>
> of how to generate static libraries should this change have unintended=
<br>
> results for other users. If you submit a patch for this, I would be<br=
>
> happy to apply it :)<br>
</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);">This will require me to study ltmain.s=
h (or whatever it is generated from) more closely, which will surely take m=
e some time, but I hope I will find time to do this. Though, I can't promis=
e it'll be soon.</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);">With the current state of things, it i=
s really hard to make use of dependencies built with different build system=
s (autotools/meson/cmake) when using MSVC, and this is really frustrating. =
I manage to workaround these issues
most of the time, but this must be really frustrating for most of the user=
s when simple things like linking against some dependency does not work.</s=
pan></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);">I hope we can improve this situation o=
ver time to make using MSVC more user friendly.</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt;" class=3D"elementToProof">
<span style=3D"color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" clas=
s=3D"elementToProof">
- Kirill Makurin</div>
</body>
</html>
--_000_LV5PR05MB998298C1DF40453851A9A0C073B16EALV5PR05MB998298_--