From @kmx

Created by kmx@cpan.org

Please consider the following patch_

--- C:\strawberry_build\build\perl_core\perl-5.19.10\installperl.backup
Sun Oct 20 15:31:29 2013
+++ C:\strawberry_build\build\perl_core\perl-5.19.10\installperl Mon Apr
7 17:45:05 2014
@@ -260,7 +260,7 @@
if ($Is_Cygwin) {
$perldll = $libperl;
} else {
- $perldll = 'perl5'.$Config{patchlevel}.'.'.$dlext;
+ $perldll = 'perl5'.$Config{patchlevel}.'.'.$so;
}

It handles correctly the situation when you have for example $Config{dlext}
== 'xs.dll' and $Config{so} = 'dll'

--
kmx

Flags:
     category=install
     severity=low

Site configuration information for perl 5.19.10:

Configured by strawberry-perl at Sun Apr  6 08:27:02 2014.

Summary of my perl5 (revision 5 version 19 subversion 10) configuration:

   Platform:
     osname=MSWin32, osvers=6.2, archname=MSWin32-x86-multi-thread-64int
     uname='Win32 strawberry-perl 5.19.10.1-beta1 #1 Sun Apr  6 08:25:20 
2014 i386'
     config_args='undef'
     hint=recommended, useposix=true, d_sigaction=undef
     useithreads=define, usemultiplicity=define
     use64bitint=define, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='gcc', ccflags =' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS 
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO 
-fno-strict-aliasing -mms-bitfields',
     optimize='-s -O2',
     cppflags='-DWIN32'
     ccversion='', gccversion='4.8.2', gccosandvers=''
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
     ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long 
long', lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='g++.exe', ldflags ='-s -L"C:\tmp32\perl\lib\CORE" -L"C:\tmp32\c\lib"'
     libpth=C:\tmp32\c\lib C:\tmp32\c\i686-w64-mingw32\lib 
C:\tmp32\c\lib\gcc\i686-w64-mingw32\4.8.2
     libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
     perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
     libc=, so=dll, useshrplib=true, libperl=libperl519.a
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' '
     cccdlflags=' ', lddlflags='-mdll -s -L"C:\tmp32\perl\lib\CORE" 
-L"C:\tmp32\c\lib"'



@INC for perl 5.19.10:
     C:/tmp32/perl/site/lib/MSWin32-x86-multi-thread-64int
     C:/tmp32/perl/site/lib
     C:/tmp32/perl/vendor/lib
     C:/tmp32/perl/lib
     .


Environment for perl 5.19.10:
     HOME (unset)
     LANG (unset)
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
PATH=C:\tmp32\perl\site\bin;C:\tmp32\perl\bin;C:\tmp32\c\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0
     PERL_BADLANG (unset)
     SHELL (unset)

From @bulk88

On Mon Apr 07 13​:22​:56 2014, kmxx wrote​:

Please consider the following patch_

--- C​:\strawberry_build\build\perl_core\perl-
5.19.10\installperl.backup
Sun Oct 20 15​:31​:29 2013
+++ C​:\strawberry_build\build\perl_core\perl-5.19.10\installperl Mon
Apr
7 17​:45​:05 2014
@​@​ -260,7 +260,7 @​@​
if ($Is_Cygwin) {
$perldll = $libperl;
} else {
- $perldll = 'perl5'.$Config{patchlevel}.'.'.$dlext;
+ $perldll = 'perl5'.$Config{patchlevel}.'.'.$so;
}

It handles correctly the situation when you have for example
$Config{dlext}
== 'xs.dll' and $Config{so} = 'dll'

And why would there be such a situation (where the 2 are different)?

--
bulk88 ~ bulk88 at hotmail.com

The RT System itself - Status changed from 'new' to 'open'

From @kmx

On 8.4.2014 1​:35, bulk88 via RT wrote​:

On Mon Apr 07 13​:22​:56 2014, kmxx wrote​:

Please consider the following patch_

--- C​:\strawberry_build\build\perl_core\perl-
5.19.10\installperl.backup
Sun Oct 20 15​:31​:29 2013
+++ C​:\strawberry_build\build\perl_core\perl-5.19.10\installperl Mon
Apr
7 17​:45​:05 2014
@​@​ -260,7 +260,7 @​@​
if ($Is_Cygwin) {
$perldll = $libperl;
} else {
- $perldll = 'perl5'.$Config{patchlevel}.'.'.$dlext;
+ $perldll = 'perl5'.$Config{patchlevel}.'.'.$so;
}

It handles correctly the situation when you have for example
$Config{dlext}
== 'xs.dll' and $Config{so} = 'dll'

And why would there be such a situation (where the 2 are different)?

For example if you have XS module like Module​::Something where
Something.dll exists in c​:\windows\system32\Something.dll then the perl
loadable module ...\lib\auto\Module\Something\Something.dll fails to load
if it has c​:\windows\system32\Something.dll as a dependency.

I have currently a reported issue related to c​:\windows\system32\OpenCL.dll
+ in the past (IIRC) there was similar issue with
c​:\windows\system32\version.dll

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40

So it might be better to have $Config{dlext} something like 'xs.dll'

--
kmx

From @sisyphus

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40

With PGPLOT we got around (what I think is) the same problem by inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
  local $DynaLoader​::dl_dlext = 'xs.dll';
  }
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads it).

Cheers,
Rob

From @kmx

On 8.4.2014 12​:17, Sisyphus via RT wrote​:

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40
With PGPLOT we got around (what I think is) the same problem by inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
local $DynaLoader​::dl_dlext = 'xs.dll';
}
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads it).

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

2/ I am seriously considering to set $Config{dlext} = 'xs.dll' for
strawberry perl 5.20.x series. And IMO it is worth considering to change
default value $Config{dlext} = 'xs.dll' for Win32 since 5.21.0.

Those are two issues, in this RT I only want to fix 1/

--
kmx

From @Hugmeir

On Tue, Apr 8, 2014 at 12​:48 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 12​:17, Sisyphus via RT wrote​:

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40

With PGPLOT we got around (what I think is) the same problem by inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
local $DynaLoader​::dl_dlext = 'xs.dll';
}
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads it).

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

2/ I am seriously considering to set $Config{dlext} = 'xs.dll' for
strawberry perl 5.20.x series. And IMO it is worth considering to change
default value $Config{dlext} = 'xs.dll' for Win32 since 5.21.0.

Those are two issues, in this RT I only want to fix 1/

This looks like the same issue that Android had regarding library
names. Can you try building with
d_libname_unique='define'? I haven't had the chance to test that on
Windows, but odds are that it'll work just fine.

From @craigberry

On Tue, Apr 8, 2014 at 6​:48 AM, Brian Fraser <fraserbn@​gmail.com> wrote​:

This looks like the same issue that Android had regarding library
names. Can you try building with
d_libname_unique='define'? I haven't had the chance to test that on
Windows, but odds are that it'll work just fine.

My thoughts exactly. Fixing the filename by overloading the extension
seems a bit hackish when there is already a solution for preventing
filename conflicts directly.

From @kmx

On 8.4.2014 13​:49, Brian Fraser via RT wrote​:

On Tue, Apr 8, 2014 at 12​:48 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 12​:17, Sisyphus via RT wrote​:

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40
With PGPLOT we got around (what I think is) the same problem by inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
local $DynaLoader​::dl_dlext = 'xs.dll';
}
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads it).

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

2/ I am seriously considering to set $Config{dlext} = 'xs.dll' for
strawberry perl 5.20.x series. And IMO it is worth considering to change
default value $Config{dlext} = 'xs.dll' for Win32 since 5.21.0.

Those are two issues, in this RT I only want to fix 1/

This looks like the same issue that Android had regarding library
names. Can you try building with
d_libname_unique='define'? I haven't had the chance to test that on
Windows, but odds are that it'll work just fine.

Thanks for the hint, on Windows it produces names like​:
...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.dll
which is fine.

I'll try to check whether all 300+ modules from CPAN bundled with
strawberry perl install fine with this setup.

--
kmx

From @Hugmeir

On Tue, Apr 8, 2014 at 2​:34 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 13​:49, Brian Fraser via RT wrote​:

On Tue, Apr 8, 2014 at 12​:48 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 12​:17, Sisyphus via RT wrote​:

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40

With PGPLOT we got around (what I think is) the same problem by
inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
local $DynaLoader​::dl_dlext = 'xs.dll';
}
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built
during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads
it).

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

2/ I am seriously considering to set $Config{dlext} = 'xs.dll' for
strawberry perl 5.20.x series. And IMO it is worth considering to change
default value $Config{dlext} = 'xs.dll' for Win32 since 5.21.0.

Those are two issues, in this RT I only want to fix 1/

This looks like the same issue that Android had regarding library
names. Can you try building with
d_libname_unique='define'? I haven't had the chance to test that on
Windows, but odds are that it'll work just fine.

Thanks for the hint, on Windows it produces names like​:
...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.dll
which is fine.

I'll try to check whether all 300+ modules from CPAN bundled with strawberry
perl install fine with this setup.

Some stuff will fail due to ExtUtils​::Depends -- there's a patch in
its RT, but it hasn't been applied yet.

From @kmx

On 8.4.2014 14​:46, Brian Fraser via RT wrote​:

On Tue, Apr 8, 2014 at 2​:34 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 13​:49, Brian Fraser via RT wrote​:

On Tue, Apr 8, 2014 at 12​:48 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 12​:17, Sisyphus via RT wrote​:

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40
With PGPLOT we got around (what I think is) the same problem by
inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
local $DynaLoader​::dl_dlext = 'xs.dll';
}
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built
during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads
it).

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

2/ I am seriously considering to set $Config{dlext} = 'xs.dll' for
strawberry perl 5.20.x series. And IMO it is worth considering to change
default value $Config{dlext} = 'xs.dll' for Win32 since 5.21.0.

Those are two issues, in this RT I only want to fix 1/

This looks like the same issue that Android had regarding library
names. Can you try building with
d_libname_unique='define'? I haven't had the chance to test that on
Windows, but odds are that it'll work just fine.

Thanks for the hint, on Windows it produces names like​:
...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.dll
which is fine.

I'll try to check whether all 300+ modules from CPAN bundled with strawberry
perl install fine with this setup.

Some stuff will fail due to ExtUtils​::Depends -- there's a patch in
its RT, but it hasn't been applied yet.

That is funny as even the hack via $Config{dlext} = 'xs.dll' requires
ExtUtils​::Depends patch :)
https://rt.cpan.org/Ticket/Display.html?id=94515

--
kmx

From @Leont

On Tue, Apr 8, 2014 at 12​:48 PM, kmx <kmx@​volny.cz> wrote​:

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

The two are not equal on pretty much any non-ELF unix, most notably darwin
and aix. So generally speaking this is legal.

dlext is the extension for a dynamically loadable extension. so is the
extension for a library (shared object). So in this particular case, the
s/dlext/so/ patch seems to be the correct thing, regardless of any changes
to dlext's value.

Leon

From @kmx

On 8.4.2014 14​:46, Brian Fraser via RT wrote​:

On Tue, Apr 8, 2014 at 2​:34 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 13​:49, Brian Fraser via RT wrote​:

On Tue, Apr 8, 2014 at 12​:48 PM, kmx <kmx@​volny.cz> wrote​:

On 8.4.2014 12​:17, Sisyphus via RT wrote​:

-----Original Message-----
From​: kmx

Also troubles with LibXSLT.dll that got fixed by this ugly hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/Makefile.PL#L227
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.89/LibXSLT.pm#L40
With PGPLOT we got around (what I think is) the same problem by
inserting
the desired DLEXT setting into %WriteMakefile (in the Makefile.PL)​:
$items{DLEXT} = "xs.dll" if $is_win32;

and then assigning 'xs.dll' to $DynaLoader​::dl_dlext in PGPLOT.pm​:

if($^O =~ /mswin32/i) {
local $DynaLoader​::dl_dlext = 'xs.dll';
}
bootstrap PGPLOT $VERSION;

See​:
http​://search.cpan.org/src/KGB/PGPLOT-2.21/Makefile.PL
http​://search.cpan.org/src/KGB/PGPLOT-2.21/PGPLOT.pm

That was all that was needed to ensure that the dll that gets built
during
the PGPLOT build is named 'PGPLOT.xs.dll' (and that DynaLoader loads
it).

You are right, on the other hand changing $Config{dlext} could solve it
globally.

Anyway​:

1/ what I suggest in this RT is a simple patch that fixes currently
incorrect behaviour (assuming that having $Config{dlext} not equal to
$Config{so} is legal option)

2/ I am seriously considering to set $Config{dlext} = 'xs.dll' for
strawberry perl 5.20.x series. And IMO it is worth considering to change
default value $Config{dlext} = 'xs.dll' for Win32 since 5.21.0.

Those are two issues, in this RT I only want to fix 1/

This looks like the same issue that Android had regarding library
names. Can you try building with
d_libname_unique='define'? I haven't had the chance to test that on
Windows, but odds are that it'll work just fine.

Thanks for the hint, on Windows it produces names like​:
...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.dll
which is fine.

I'll try to check whether all 300+ modules from CPAN bundled with strawberry
perl install fine with this setup.

Some stuff will fail due to ExtUtils​::Depends -- there's a patch in
its RT, but it hasn't been applied yet.

The patch for ExtUtils​::Depends does not work well with Windows +
d_libname_unique='define'

The idea behind your patch was to have (in case of MS Windows)​:

...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.dll
...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.a

or​:

...\lib\auto\Compress\Raw\Zlib\PL_Compress__Raw__Zlib.dll
...\lib\auto\Compress\Raw\Zlib\Zlib.a

?

--
kmx

@kmx did you come to a conclusion on this?

Strawberry perl uses $Config{dlext} = 'xs.dll' for many years and nobody complained. I am fine with closing this issue.