develooper Front page | perl.perl5.porters | Postings from September 2019

make Config{d_libname_unique} = true for windows

From:
Ivan Baidakou
Date:
September 13, 2019 16:20
Subject:
make Config{d_libname_unique} = true for windows
Message ID:
20190913191948.609edb06@crazypanda.ru
Hello,

In strawberry perl mail list I was adviced to suggest to make 

Config{d_libname_unique} = true

by default on Windows [1].

The problem (on windows):

 when a B.dll is linked with other A.dll (1)
and the dll with exactly the same name was loaded before (A.dll(2)), 
then on loading B.dll fails (as it tries to resolve symbols for B.dll 
on behalf of A.dll(2)). 

I created an sample CMake-based project to demonstrate an issue
(I used boost to load dlls) [2]. See the sample output [3].

1. If it loads A.dll(1) (which is dependency of B.dll), then another A.dll(2)
, then B.dll- all OK. B.dll symbols are resolved/linked correctly

2. If it loads other A.dll(2), then another A.dll(1), and then B.dll, it 
crashes.

3. If A.dll(1) will be renamed to whatever, i.e. A2.dll, then 
A.dll, A2.dll, B.dll are loded correctly and all is OK.


We have met exactly the same issue on strawberry perl, because 
of sharing the same dll base name:
1. There is a module next::xs (xs.dll)
2. There is a module XS::Framework (framework.dll, which is linked to
next::xs)
3. There is a module Export::XS (xs.dll, again)
4. There is a module Time::XS (xs.dll), which is binary linked with
XS::Framework and Export::XS, and Windows fails to load it. 

Having unique base names will solve the problem. 


[1] https://www.mail-archive.com/win32-vanilla@perl.org/msg00703.html

[2] https://github.com/basiliscos/cpp-so-problem

[3] https://i.imgur.com/yVsyNHR.png



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About