Re: why $Config{d_libname_unique} = undef for strawberry perl (DynaLoader.pm) ?

--00000000000091385905923e143e
Content-Type: multipart/alternative; boundary="00000000000091385705923e143c"

--00000000000091385705923e143c
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 11, 2019 at 3:27 AM Ivan Baidakou <[email protected]>
wrote:

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

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".
#################

Also, on my (Ubuntu-18.04) Linux box, d_libname_unique is undef but there's
no issues with these modules there.

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.

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.

Cheers,
Rob

--00000000000091385705923e143c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div cl=
ass=3D"gmail_attr" dir=3D"ltr">On Wed, Sep 11, 2019 at 3:27 AM Ivan Baidako=
u &lt;<a href=3D"mailto:[email protected]">[email protected]<=
/a>&gt; wrote:</div><div class=3D"gmail_attr" dir=3D"ltr"><br></div><div cl=
ass=3D"gmail_attr" dir=3D"ltr">&gt; It seem, that the option $Config{d_libn=
ame_unique} would solve=C2=A0the problem, however it is off on Strawberry p=
erl builds. </div><div class=3D"gmail_attr" dir=3D"ltr"><br></div><div clas=
s=3D"gmail_attr">I don&#39;t think the state of d_libname_unique is the iss=
ue.</div><div class=3D"gmail_attr">According to the Config docs:</div><div =
class=3D"gmail_attr"><br></div><div class=3D"gmail_attr">##################=
</div><div class=3D"gmail_attr">&quot;d_libname_unique&quot;<br>From so.U:<=
/div><div class=3D"gmail_attr">=C2=A0This variable is defined if the target=
 system insists on unique basenames for shared library files. This is curre=
ntly true on Android, false everywhere else we know of. Defaults to &quot;u=
ndef&quot;.</div><div class=3D"gmail_attr">#################</div><div clas=
s=3D"gmail_attr"><br></div><div class=3D"gmail_attr">Also, on my (Ubuntu-18=
.04) Linux box, d_libname_unique is undef but there&#39;s no issues with th=
ese modules there.</div><div class=3D"gmail_attr"><br></div><div class=3D"g=
mail_attr">I thought it might have something to do with the &#39;.xs.dll&#3=
9; ending that Strawberry uses, but that&#39;s not the case.</div><div clas=
s=3D"gmail_attr">On my Windows perls where the ending is just plain &quot;.=
dll&#39; I still hit the issue you&#39;re seeing.</div><div class=3D"gmail_=
attr"><br></div><div class=3D"gmail_attr">The fix that I=C2=A0would use is=
=C2=A0(for Windows only) to have next::XS create a dll that has a unique na=
me (say XS.next.dll) and Export::XS to likewise=C2=A0create a=C2=A0uniquely=
 named XS.expt.dll.</div><div class=3D"gmail_attr">The attached patches ach=
ieves this, though I didn&#39;t check to see whether it was necessary to un=
iquely name *both* next::XS and Export::XS dlls.</div><div class=3D"gmail_a=
ttr"><br></div><div class=3D"gmail_attr"><div class=3D"gmail_attr">This is =
a very low-traffic list, and I&#39;m not sure who&#39;s here.</div><div cla=
ss=3D"gmail_attr">I thought a better way of reporting it might be to raise =
an &quot;Issue&quot; at <a href=3D"https://github.com/StrawberryPerl/Perl-D=
ist-Strawberry">https://github.com/StrawberryPerl/Perl-Dist-Strawberry</a> =
, but I don&#39;t see an &quot;Issues&quot; button there. (Perhaps just bad=
 vision on my part.)</div><div class=3D"gmail_attr">In any case, I think it=
&#39;s probably some quirk of Windows that *you* (and not=C2=A0the Strawber=
ry Perl developers) will have to attend to.</div></div><div class=3D"gmail_=
attr"><br></div><div class=3D"gmail_attr">Cheers,<br>Rob</div><div class=3D=
"gmail_attr"><br></div><div class=3D"gmail_attr"><br></div><div class=3D"gm=
ail_attr"><br></div><div class=3D"gmail_attr"><br></div>
</div></div></div></div></div></div>

--00000000000091385705923e143c--
--00000000000091385905923e143e
Content-Type: text/plain; charset="US-ASCII"; name="export.patch.txt"
Content-Disposition: attachment; filename="export.patch.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_k0enwme40>
X-Attachment-Id: f_k0enwme40

LS0tIE1ha2VmaWxlLlBMX29yaWcJMjAxOS0wOS0xMSAxMTo0ODo0MSArMTAwMA0KKysrIE1ha2Vm
aWxlLlBMCTIwMTktMDktMTEgMTE6NTI6NDggKzEwMDANCkBAIC0xLDcgKzEsNyBAQA0KIHVzZSBz
dHJpY3Q7DQogdXNlIFhTOjpJbnN0YWxsOw0KIA0KLXdyaXRlX21ha2VmaWxlKA0KK215ICVwYXJh
bXMgPSAoDQogICAgIE5BTUUgICAgICAgICAgPT4gJ0V4cG9ydDo6WFMnLA0KICAgICBDUExVUyAg
ICAgICAgID0+IDExLA0KICAgICBTUkMgICAgICAgICAgID0+ICdzcmMnLA0KQEAgLTExLDMgKzEx
LDcgQEANCiAgICAgQklOX0RFUFMgICAgICA9PiAnWFM6OkZyYW1ld29yaycsDQogICAgIEJJTl9T
SEFSRSAgICAgPT4ge0lOQ0xVREUgID0+IHsnc3JjJyA9PiAnLyd9fSwNCiApOw0KKw0KKyRwYXJh
bXN7RExFWFR9ID0gJ2V4cHQuZGxsJyBpZiAkXk8gPX4gL01TV2luMzIvOw0KKw0KK3dyaXRlX21h
a2VmaWxlKCVwYXJhbXMpOw0KLS0tIGxpYi9leHBvcnQvWFMucG1fb3JpZwkyMDE5LTA5LTExIDEx
OjUxOjQxICsxMDAwDQorKysgbGliL2V4cG9ydC9YUy5wbQkyMDE5LTA5LTExIDEyOjI3OjA5ICsx
MDAwDQpAQCAtNCw2ICs0LDggQEANCiANCiBvdXIgJFZFUlNJT04gPSAnMy4wLjAnOw0KIA0KK2xv
Y2FsICREeW5hTG9hZGVyOjpkbF9kbGV4dCA9ICdleHB0LmRsbCcgaWYgJF5PID1+IC9NU1dpbjMy
LzsNCisNCiBYUzo6TG9hZGVyOjpsb2FkKCk7DQogDQogcmVxdWlyZSBFeHBvcnQ6OlhTOjpBdXRv
Ow0K
--00000000000091385905923e143e
Content-Type: text/plain; charset="US-ASCII"; name="next.patch.txt"
Content-Disposition: attachment; filename="next.patch.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_k0enxicd1>
X-Attachment-Id: f_k0enxicd1

LS0tIE1ha2VmaWxlLlBMX29yaWcJMjAxOS0wOS0xMSAxMTo0MDo0NSArMTAwMA0KKysrIE1ha2Vm
aWxlLlBMCTIwMTktMDktMTEgMTE6Mzc6MzIgKzEwMDANCkBAIC0xMiw0ICsxMiw2IEBADQogICAg
IEJJTl9TSEFSRSAgICAgICAgPT4ge0lOQ0xVREUgID0+IHsnc3JjJyA9PiAnLyd9fSwNCiApOw0K
IA0KKyRwYXJhbXN7RExFWFR9ID0gJ25leHQuZGxsJyBpZiAkXk8gPX4gL01TV2luMzIvOw0KKw0K
IHdyaXRlX21ha2VmaWxlKCVwYXJhbXMpOw0KLS0tIGxpYi9uZXh0L1hTLnBtX29yaWcJMjAxOS0w
OS0xMSAxMToyMzo1NCArMTAwMA0KKysrIGxpYi9uZXh0L1hTLnBtCTIwMTktMDktMTEgMTI6MjQ6
NTcgKzEwMDANCkBAIC00LDYgKzQsNyBAQA0KIHVzZSBYUzo6TG9hZGVyOw0KIA0KIG91ciAkVkVS
U0lPTiA9ICcxLjAuNyc7DQorbG9jYWwgJER5bmFMb2FkZXI6OmRsX2RsZXh0ID0gJ25leHQuZGxs
JyBpZiAkXk8gPX4gL01TV2luMzIvOw0KIA0KIHsNCiAgICAgbG9jYWwgJF5XOw0K
--00000000000091385905923e143e--