Our company develops a CPAN XS-modules; while our main platform is
Linux, we'd like to let them work on Windows too.

Today, we were able to find the following issue, related to the NOT
ENABLED $Config{d_libname_unique} on Windows:

1. The next::XS module has XS.xs.dll;

2. The XS::Framework (Framework.xs.dll) depends on next::XS;

3. The Export::XS has also "XS.xs.dll"; 

4. The Time::XS has also "XS.xs.dll", which has binary dependency on
XS::Framework and on Export::XS. 

Let's assume that the modules XS::Framework and Export::XS are 
already loaded an bootstrapped. 

So, when any other module tries to load Time::XS, the win32 call 
LoadLibraryExA("/path/to/time-xs/XS.xs.dll") returns the error
code 127, because it cannot figure out, which one of it's 
already loaded binary depencies (XS.xs.dll from next::XS or XS.xs.dll
from Export::XS) it should use. 

We have checked, that if DLLs filenames are unique, the error does
not happen and everything works as expected. 

It seem, that the option $Config{d_libname_unique} would solve 
the problem, however it is off on Strawberry perl builds. 

Why so? Can we hope, that it be enabled if future releases? 

WBR, basiliscos.

Reply via email to