> I don't think the state of d_libname_unique is the issue.
> According to the Config docs:
>
> ##################
> "d_libname_unique"
> From so.U:
> This variable is defined if the target system insists on unique basenames
> for shared library files. This is currently true on Android, false
> everywhere else we know of. Defaults to "undef".
> #################
It is *exactly* what we wanted. According to my searches, when b.dll dpends
on a.dll, there is no path hard-coded inside b.dll, where to look for a.dll,
only its base name.
> Also, on my (Ubuntu-18.04) Linux box, d_libname_unique is undef but there's
> no issues with these modules there.
I have linux too, and that option is also off. This works, as linux linker
links the full path to the dependencies, i.e.
ldd .../var/lib/x86_64-linux/auto/Geo/Geos/Geos.so
linux-vdso.so.1 (0x00007ffeabe65000)
/home/b/development/crazy-panda/realcraft-geos/meia/var/lib/x86_64-linux/auto/CPP/geos/geos.so
(0x00007f4bfeb70000)
/home/b/development/crazy-panda/realcraft-geos/meia/var/lib/x86_64-linux/auto/Export/XS/XS.so
(0x00007f4bfeb62000)
/home/b/development/crazy-panda/realcraft-geos/meia/var/lib/x86_64-linux/auto/next/XS/XS.so
(0x00007f4bfeb56000)
/home/b/development/crazy-panda/realcraft-geos/meia/var/lib/x86_64-linux/auto/CPP/panda/lib/lib.so
(0x00007f4bfeb1f000)
/home/b/development/crazy-panda/realcraft-geos/meia/var/lib/x86_64-linux/auto/XS/Framework/Framework.so
(0x00007f4bfeaf9000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f4bfe862000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f4bfe71d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f4bfe703000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f4bfe540000)
/lib/ld-linux-x86-64.so.2 (0x00007f4bfee38000)
>
> I thought it might have something to do with the '.xs.dll' ending that
> Strawberry uses, but that's not the case.
> On my Windows perls where the ending is just plain ".dll' I still hit the
> issue you're seeing.
>
> The fix that I would use is (for Windows only) to have next::XS create a
> dll that has a unique name (say XS.next.dll) and Export::XS to
> likewise create a uniquely named XS.expt.dll.
> The attached patches achieves this, though I didn't check to see whether it
> was necessary to uniquely name *both* next::XS and Export::XS dlls.
Thank you. Your solution is a bit simplier, than ours idea to localize
"mod2fname",
we'll try it.
>
> This is a very low-traffic list, and I'm not sure who's here.
> I thought a better way of reporting it might be to raise an "Issue" at
> https://github.com/StrawberryPerl/Perl-Dist-Strawberry , but I don't see an
> "Issues" button there. (Perhaps just bad vision on my part.)
> In any case, I think it's probably some quirk of Windows that *you* (and
> not the Strawberry Perl developers) will have to attend to.
It is a bit sad if strawberry-perl devs aren't reacheable via official
mail-list listed on the site.
As this is generic issue on Windows-platform, I think it should be fixed in
via enabling d_libname_unique. It would be nice to hear devs, why not
enable this option.
