From @kmx

Created by kmx@cpan.org

I have experienced a collision in DLL names when playing with SDL2 perl
bindings.

The trouble is that SDL2 (external library) binaries comes with SDL2.dll file.

However if you have SDL2 perl module implemented in SDL2.xs the output of
building this module will be SDL2.dll which is (has to be) linked with DLL
of SDL2 external library (also named SDL2.dll) which causes a fatal error.

It is a generic problem - for example XML​::LibXSLT avoids LibXSLT.dll
collision with this hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.80/LibXSLT.pm#L36

Would it be possible to change naming convention for DLL's produced from *.xs
files to be for example Module.xs.dll not Module.dll ?

Flags:
     category=core
     severity=low

Site configuration information for perl 5.16.2:

Configured by strawberry-perl at Sat Feb 23 20:33:30 2013.

Summary of my perl5 (revision 5 version 16 subversion 2) configuration:

   Platform:
     osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
     uname='Win32 strawberry-perl 5.16.2.2 #1 Sat Feb 23 20:32:29 2013 i386'
     config_args='undef'
     hint=recommended, useposix=true, d_sigaction=undef
     useithreads=define, usemultiplicity=define
     useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
     use64bitint=undef, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='gcc', ccflags =' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS 
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing 
-mms-bitfields',
     optimize='-s -O2',
     cppflags='-DWIN32'
     ccversion='', gccversion='4.6.3', gccosandvers=''
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
     d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', 
lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='g++.exe', ldflags ='-s -L"Z:\spp32_51622\perl\lib\CORE" 
-L"Z:\spp32_51622\c\lib"'
     libpth=Z:\spp32_51622\c\lib Z:\spp32_51622\c\i686-w64-mingw32\lib
     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=libperl516.a
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
     cccdlflags=' ', lddlflags='-mdll -s -L"Z:\spp32_51622\perl\lib\CORE" 
-L"Z:\spp32_51622\c\lib"'

Locally applied patches:



@INC for perl 5.16.2:
     Z:/spp32_51622/perl/site/lib
     Z:/spp32_51622/perl/vendor/lib
     Z:/spp32_51622/perl/lib
     .


Environment for perl 5.16.2:
     HOME (unset)
     LANG (unset)
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
PATH=Z:\spp32_51622\perl\site\bin;Z:\spp32_51622\perl\bin;Z:\spp32_51622\c\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
     PERL_BADLANG (unset)
     SHELL (unset)

From @bulk88

On Fri Mar 01 03​:01​:20 2013, kmxx wrote​:

This is a bug report for perl from kmx@​cpan.org,
generated with the help of perlbug 1.39 running under perl 5.16.2.

-----------------------------------------------------------------
[Please describe your issue here]

I have experienced a collision in DLL names when playing with SDL2
perl
bindings.

The trouble is that SDL2 (external library) binaries comes with
SDL2.dll file.

However if you have SDL2 perl module implemented in SDL2.xs the output
of
building this module will be SDL2.dll which is (has to be) linked with
DLL
of SDL2 external library (also named SDL2.dll) which causes a fatal
error.

It is a generic problem - for example XML​::LibXSLT avoids LibXSLT.dll
collision with this hack​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.80/LibXSLT.pm#L36

Would it be possible to change naming convention for DLL's produced
from *.xs
files to be for example Module.xs.dll not Module.dll ?

Can you post all the output of the compiler with the error you are seeing?

I dont like that idea. Some rarely used parts of Windows only work off
the first part of a DLL name, "Module", and will load try to load
"Module.dll" after parsing "Module.xs.dll". A small amount of XS DLLs
export things to other XS DLLs on Windows. Changing the name of the DLL
exporting in EUMM will break those importing modules. Also Dynaloader
would have to be changed to look for a .xs.dll file and not a .dll file.
Can't you just do "bootstrap Foo​::ModuleXS;" in the "Module.pm" file
and have a ModuleXS.xs file in the distribution when necessary for that
module?

The other less ideal choice is not to link with non-XS DLL, do a
LoadLibrary() in the XS module in BOOT​: with an absolute path to load a
2nd dll with the same name into the process, then GetProcAddress() all
the functions ptrs you need from a specific DLL handle.

For anyone who knows what MS's SXS is, skip this paragraph. SXS is a
technology MS invented in the early 2000s to deal with DLL hell, but it
really creates its own version of DLL hell and nobody but MS uses it. It
was intended to guarentee ABI compatibility of DLLs with the same
version numbers and disk file names. In process A, DLL B needs DLL D
version 1.3 build 9567, but DLL C needs DLL D version 1.3 build 9487.
But on this PC, 9487 got a security fix as was released as 9721, but
9721 isn't compatible with 9567, so DLL C will get 9721 since 9487 was
disabled in the registry (simplification) and was redirected to 9721,
but DLL B will get DLL D build 9567. There will be 2 different DLL Ds in
the process. SHA1s and crypto signing are used throughout the whole
system to make sure you can't just binary patch the DLL to inject
spyware or break DRM or something. But also upgrades to the DLL can be
temporarily redirected, per system, per user, per process, or per DLL to
an older version of the DLL or a process supplied version. That older
version can also be redirected per system, per user, per process, or per
DLL to another upgraded DLL installed globally.

The crazy choice, I dont even know if this will work, is attach SXS
manifest and version the XS DLL and the non XS DLL, not sure how to get
around the linking problems (I asked above for full compiler output).
Then when the XS DLL is loaded into the process, due to SXS, the DLL
loader will fetch the functions from the non XS DLL with same file name
but different version/manifest/SHA1, and not the same DLL that is
currently being loaded. This won't work on Windows 2000 since there is
no SXS on 2000.

The other possibility, also IDK if this will work is, is if you can
trick the linker into making the XS DLL, before doing bootstrap, do a
Win32​::LoadLibrary on the non-XS DLL, then do the bootstrap as normal,
then during the loading process, the XS DLL isn't registered yet, but
LoadLibrary-ed non-XS is in process, and that one will be found first
(assuming) when loading the XS DLL.

Another question for thought, is this bug possible on unix if there are
2 .so with same name (the XS and non XS SO both are called "libfoo.so")
in PATH? If a SO is already in the process, will it be reused as on
Windows (
http​://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#search_order_for_desktop_applications
) ignoring the full path, or is the disk always re-searched?

--
bulk88 ~ bulk88 at hotmail.com

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

From @Leont

On Sun, Mar 3, 2013 at 5​:52 AM, bulk88 via RT <perlbug-followup@​perl.org> wrote​:

The crazy choice, I dont even know if this will work, is attach SXS
manifest and version the XS DLL and the non XS DLL, not sure how to get
around the linking problems (I asked above for full compiler output).
Then when the XS DLL is loaded into the process, due to SXS, the DLL
loader will fetch the functions from the non XS DLL with same file name
but different version/manifest/SHA1, and not the same DLL that is
currently being loaded. This won't work on Windows 2000 since there is
no SXS on 2000.

The other possibility, also IDK if this will work is, is if you can
trick the linker into making the XS DLL, before doing bootstrap, do a
Win32​::LoadLibrary on the non-XS DLL, then do the bootstrap as normal,
then during the loading process, the XS DLL isn't registered yet, but
LoadLibrary-ed non-XS is in process, and that one will be found first
(assuming) when loading the XS DLL.

DynaLoader tries to load Foo.bs before loading any Foo.so/Foo.dll.
AFAIK it was designed for this sort of issue (the only example on
CPAN/core I'm aware of is
https://metacpan.org/source/PMQS/DB_File-1.827/DB_File_BS).

Another question for thought, is this bug possible on unix if there are
2 .so with same name (the XS and non XS SO both are called "libfoo.so")
in PATH? If a SO is already in the process, will it be reused as on
Windows (
http​://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#search_order_for_desktop_applications
) ignoring the full path, or is the disk always re-searched?

On ELF linking is not keyed on filename, but on soname, a property of
the library. So a foo.so with soname foo.so.1 and another foo.so with
soname foo.so.2 will not collide. That said, we don't use sonames for
our loadable objects because that would be kind of silly anyway.

Leon

From @kmx

Can you post all the output of the compiler with the error you are seeing?

There is no compiler error.

However on runtime an error message box pops up saying​: "The procedure
entry point SomeFunctionFromExtLibrary could not be located in dynamic link
library Module.DLL."

--
kmx

From @kmx

I would like to propose again changing the defult $Config{dlext} on
MS Windows from 'dll' to 'xs.dll'

My arguments mentioned in this ticked stays the same.

Strawberry perl has switched to 'xs.dll' in 5.20.* series (more than
6 months ago) and there are no reported issues.

So it does work and it does fix the troubles mentioned earlier.

--
kmx

From @bulk88

On Tue Dec 16 00​:27​:33 2014, kmxx wrote​:

I would like to propose again changing the defult $Config{dlext} on
MS Windows from 'dll' to 'xs.dll'

My arguments mentioned in this ticked stays the same.

Strawberry perl has switched to 'xs.dll' in 5.20.* series (more than
6 months ago) and there are no reported issues.

Making things longer never causes issues since nobody will report to a software project they ran out of disk space because of that software project or paths are longer to type and a slightly larger burden to work with the project. As I said the very few cases where XS modules get in trouble by conflicting with a OS or non-C DLL name are easily fixed by renaming the XS side DLL for that module alone, not renaming all modules to fix 1 freak collision. I still disagree with this proposal.

--
bulk88 ~ bulk88 at hotmail.com

From @craigberry

On Tue, Dec 16, 2014 at 2​:27 AM, kmx via RT <perlbug-followup@​perl.org> wrote​:

I would like to propose again changing the defult $Config{dlext} on
MS Windows from 'dll' to 'xs.dll'

My arguments mentioned in this ticked stays the same.

Strawberry perl has switched to 'xs.dll' in 5.20.* series (more than
6 months ago) and there are no reported issues.

So it does work and it does fix the troubles mentioned earlier.

Have you tried configuring with d_libname_unique='define' like Android
does (and based on something VMS has done for 20+ years)? See
ext/DynaLoader/DynaLoader_pm.PL for where it creates a mod2fname
function if this feature is enabled. I think in your case you would
get PL_SDL2.dll. If there are multiple components, you get all of
them, e.g., PL_MIME__BASE64.dll

From @kmx

On 18.12.2014 23​:19, bulk88 via RT wrote​:

On Tue Dec 16 00​:27​:33 2014, kmxx wrote​:

I would like to propose again changing the defult $Config{dlext} on
MS Windows from 'dll' to 'xs.dll'

My arguments mentioned in this ticked stays the same.

Strawberry perl has switched to 'xs.dll' in 5.20.* series (more than
6 months ago) and there are no reported issues.
Making things longer never causes issues since nobody will report to a software project they ran out of disk space because of that software project or paths are longer to type and a slightly larger burden to work with the project.

I am afraid I do not understand what you wanted to say.

As I said the very few cases where XS modules get in trouble by conflicting with a OS or non-C DLL name are easily fixed by renaming the XS side DLL for that module alone, not renaming all modules to fix 1 freak collision. I still disagree with this proposal.

But "easily fixed" means quite ugly hacks like these​:
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.92/Makefile.PL#L232
https://metacpan.org/source/SHLOMIF/XML-LibXSLT-1.92/LibXSLT.pm#L40
https://metacpan.org/source/KGB/PGPLOT-2.21/Makefile.PL#L137
https://metacpan.org/source/KGB/PGPLOT-2.21/PGPLOT.pm#L30

Statistically there is pretty good chance that the module author will be
"UNIX oriented" and even if she has positive attitude to Windows platform
it will be quite tough for her to catch and fix this kind of error. On the
other hand even for a Windows user the failure is quite tricky as there is
no clear message saying "DLL name collision" but quite unusual pop up error
dialog saying something like "DLL cannot be loaded or is corrupted" which
at the first sight seems to be a compiler bug or something like that.

--
kmx

From @kmx

On 18.12.2014 23​:42, Craig A. Berry wrote​:

On Tue, Dec 16, 2014 at 2​:27 AM, kmx via RT <perlbug-followup@​perl.org> wrote​:

I would like to propose again changing the defult $Config{dlext} on
MS Windows from 'dll' to 'xs.dll'

My arguments mentioned in this ticked stays the same.

Strawberry perl has switched to 'xs.dll' in 5.20.* series (more than
6 months ago) and there are no reported issues.

So it does work and it does fix the troubles mentioned earlier.
Have you tried configuring with d_libname_unique='define' like Android
does (and based on something VMS has done for 20+ years)? See
ext/DynaLoader/DynaLoader_pm.PL for where it creates a mod2fname
function if this feature is enabled. I think in your case you would
get PL_SDL2.dll. If there are multiple components, you get all of
them, e.g., PL_MIME__BASE64.dll

I know about d_libname_unique option, I have tested it, it works fine with
MS Windows and it also fixes the troubles we are talking about here.

Considering objections about too long paths I think that dlext is a bit
better (shorter).

--
kmx

From @bulk88

On Thu Dec 18 14​:42​:33 2014, craig.a.berry@​gmail.com wrote​:

Have you tried configuring with d_libname_unique='define' like Android
does (and based on something VMS has done for 20+ years)? See
ext/DynaLoader/DynaLoader_pm.PL for where it creates a mod2fname
function if this feature is enabled. I think in your case you would
get PL_SDL2.dll. If there are multiple components, you get all of
them, e.g., PL_MIME__BASE64.dll

"dlext" smells like a 2nd implementation of "d_libname_unique", but "d_libname_unique" file names are much longer than "dlext" file names. WinCE OS will probably require "d_libname_unique" if I ever use it for something complicated since MS made an "optimization" on WinCE to stop app distributed common DLLs from chewing up the 32 MB of ram on these devices by each app having its own copy of a well known DLL.

--
bulk88 ~ bulk88 at hotmail.com

From @craigberry

On Thu, Dec 18, 2014 at 5​:07 PM, kmx <kmx@​atlas.cz> wrote​:

On 18.12.2014 23​:42, Craig A. Berry wrote​:

Have you tried configuring with d_libname_unique='define' like Android
does (and based on something VMS has done for 20+ years)?

I know about d_libname_unique option, I have tested it, it works fine with
MS Windows and it also fixes the troubles we are talking about here.

Considering objections about too long paths I think that dlext is a bit
better (shorter).

I wouldn't take the complaint about too much typing seriously; one
doesn't actually type DLL names very often. My advice would be to
just use d_libname_unique and not worry about the length (it will
limit itself to 255 characters or fewer).

I'm not fond of the dlext solution as then dlext no longer means "the
extension on a DLL" but "the extension on a DLL plus some other bits
we couldn't find a proper place to put." In other words, it's a bit
of a data model violation. It's likely something you can mostly get
away with but will have unpleasant surprises somewhere eventually.
Been there, done that.

If you don't like the names provided by the default mod2fname that you
get with d_libname_unique, you just have to define a
DynaLoader​::mod2fname function somewhere that makes the names that you
want. That's what VMS has always done in vms/vms.c and makes an
ordinary C function available to Perl like so​:

  newXSproto("DynaLoader​::mod2fname", mod2fname, file, "$");

I'm thinking of getting rid of that since there is now a pure-Perl
equivalent that does exactly the same thing if one defines
d_libname_unique. But if you want complete control over the DLL names
using a method that's been battle-tested for decades, this is it. Or
you could make platform-specific variations to mod2fname in
ext/DynaLoader/DynaLoader_pm.PL.

From @Leont

On Fri, Dec 19, 2014 at 1​:24 AM, Craig A. Berry <craig.a.berry@​gmail.com>
wrote​:

I wouldn't take the complaint about too much typing seriously; one
doesn't actually type DLL names very often. My advice would be to
just use d_libname_unique and not worry about the length (it will
limit itself to 255 characters or fewer).

I'm not fond of the dlext solution as then dlext no longer means "the
extension on a DLL" but "the extension on a DLL plus some other bits
we couldn't find a proper place to put." In other words, it's a bit
of a data model violation. It's likely something you can mostly get
away with but will have unpleasant surprises somewhere eventually.
Been there, done that.

If you don't like the names provided by the default mod2fname that you
get with d_libname_unique, you just have to define a
DynaLoader​::mod2fname function somewhere that makes the names that you
want. That's what VMS has always done in vms/vms.c and makes an
ordinary C function available to Perl like so​:

newXSproto("DynaLoader​::mod2fname", mod2fname, file, "$");

I'm thinking of getting rid of that since there is now a pure-Perl
equivalent that does exactly the same thing if one defines
d_libname_unique. But if you want complete control over the DLL names
using a method that's been battle-tested for decades, this is it. Or
you could make platform-specific variations to mod2fname in
ext/DynaLoader/DynaLoader_pm.PL.

This would be my general sentiment too.

Leon

From @kmx

On 19.12.2014 1​:49, Leon Timmermans wrote​:

On Fri, Dec 19, 2014 at 1​:24 AM, Craig A. Berry <craig.a.berry@​gmail.com
<mailto​:craig.a.berry@​gmail.com>> wrote​:

I wouldn't take the complaint about too much typing seriously; one
doesn't actually type DLL names very often\.  My advice would be to
just use d\_libname\_unique and not worry about the length \(it will
limit itself to 255 characters or fewer\)\.

I'm not fond of the dlext solution as then dlext no longer means "the
extension on a DLL" but "the extension on a DLL plus some other bits
we couldn't find a proper place to put\."  In other words\, it's a bit
of a data model violation\.  It's likely something you can mostly get
away with but will have unpleasant surprises somewhere eventually\.
Been there\, done that\.

If you don't like the names provided by the default mod2fname that you
get with d\_libname\_unique\, you just have to define a
DynaLoader​::mod2fname function somewhere that makes the names that you
want\.  That's what VMS has always done in vms/vms\.c and makes an
ordinary C function available to Perl like so​:

  newXSproto\("DynaLoader​::mod2fname"\, mod2fname\, file\, "$"\);

I'm thinking of getting rid of that since there is now a pure\-Perl
equivalent that does exactly the same thing if one defines
d\_libname\_unique\.  But if you want complete control over the DLL names
using a method that's been battle\-tested for decades\, this is it\.  Or
you could make platform\-specific variations to mod2fname in
ext/DynaLoader/DynaLoader\_pm\.PL\.

This would be my general sentiment too.

I have done some serious testing of both d_libname_unique and dlext options
approx. in May before 5.20.0 release.

I do not remember exactly but there were a bit more troubles with
d_libname_unique as there are some modules on CPAN that simply does not
work and fixes are not trivial (like Prima, Win32​::GUI, PAR​::Packer). One
advantage of dlext approach was that when Module.xs.dll is not found
dynaloader also tries Module.dll (as it turned out that even strawberry
perl users are using pre-built ppm packages).

To sum up​: although d_libname_unique approach might be technically
cleaner/nicer, switching Windows default to it will be definitely even more
controversial.

--
kmx

From @bulk88

On Thu Dec 18 17​:07​:33 2014, kmx@​atlas.cz wrote​:

I do not remember exactly but there were a bit more troubles with
d_libname_unique as there are some modules on CPAN that simply does not
work and fixes are not trivial (like Prima, Win32​::GUI, PAR​::Packer). One
advantage of dlext approach was that when Module.xs.dll is not found
dynaloader also tries Module.dll (as it turned out that even strawberry
perl users are using pre-built ppm packages).

You probably hit the problem I described in https​://rt.perl.org/Ticket/Display.html?id=117001#txn-1197671 where 1 XS DLL links to the exports of another XS DLL, real world example https://metacpan.org/source/JDB/Win32-OLE-0.1712/Makefile.PL#L24 (IDK what modules import those 4 funcs tho, but they are being exported for other XS DLLs to use).

--
bulk88 ~ bulk88 at hotmail.com

From @bulk88

On Thu Dec 18 17​:30​:11 2014, bulk88 wrote​:

You probably hit the problem I described in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=117001#txn-1197671 where 1
XS DLL links to the exports of another XS DLL, real world example
https://metacpan.org/source/JDB/Win32-OLE-0.1712/Makefile.PL#L24 (IDK
what modules import those 4 funcs tho, but they are being exported for
other XS DLLs to use).

I've attached Glib the XS module's export table, it is very extensive.

--
bulk88 ~ bulk88 at hotmail.com

From @bulk88

Microsoft (R) COFF/PE Dumper Version 7.10.6030
Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file glib.dll

File Type​: DLL

  Section contains the following exports for Glib.dll

  00000000 characteristics
  4E710AB5 time date stamp Wed Sep 14 16​:12​:37 2011
  0.00 version
  1 ordinal base
  163 number of functions
  163 number of names

  ordinal hint RVA name

  1 0 000014C4 SvGChar
  2 1 0000102D SvGKeyFile
  3 2 0000169F SvGParamFlags
  4 3 00001217 SvGParamSpec
  5 4 00001168 SvGSignalFlags
  6 5 000015A5 __gperl_call_XS
  7 6 0000166D _boot_Glib
  8 7 00001078 _gperl_alloc_temp
  9 8 00001429 _gperl_argv_free
  10 9 000011F4 _gperl_argv_new
  11 A 000015A0 _gperl_argv_update
  12 B 000016AE _gperl_boxed_package_from_type
  13 C 00001055 _gperl_boxed_type_from_package
  14 D 000015A5 _gperl_call_XS
  15 E 0000105F _gperl_callback_destroy
  16 F 000012A3 _gperl_callback_invoke
  17 10 00001339 _gperl_callback_new
  18 11 00001320 _gperl_closure_new
  19 12 000012C1 _gperl_closure_new_with_marshaller
  20 13 00001032 _gperl_convert_back_enum
  21 14 00001190 _gperl_convert_back_enum_pass_unknown
  22 15 0000135C _gperl_convert_back_flags
  23 16 0000144C _gperl_convert_enum
  24 17 00001384 _gperl_convert_flag_one
  25 18 00001587 _gperl_convert_flags
  26 19 00001073 _gperl_croak_gerror
  27 1A 0000116D _gperl_default_boxed_wrapper_class
  28 1B 0000119A _gperl_filename_from_sv
  29 1C 000011EA _gperl_format_variable_for_output
  30 1D 000014B0 _gperl_fundamental_package_from_type
  31 1E 0000126C _gperl_fundamental_type_from_package
  32 1F 000013DE _gperl_gerror_from_sv
  33 20 00001294 _gperl_get_boxed_check
  34 21 00001163 _gperl_get_object
  35 22 00001681 _gperl_get_object_check
  36 23 000010F0 _gperl_handle_logs_for
  37 24 00001393 _gperl_install_exception_handler
  38 25 00001366 _gperl_new_boxed
  39 26 000014BF _gperl_new_boxed_copy
  40 27 00001014 _gperl_new_object
  41 28 00001488 _gperl_object_check_type
  42 29 000010AA _gperl_object_package_from_type
  43 2A 0000114F _gperl_object_set_no_warn_unreg_subclass
  44 2B 00001226 _gperl_object_stash_from_type
  45 2C 000016C7 _gperl_object_type_from_package
  46 2D 00001677 _gperl_option_context_get_type
  47 2E 000016A9 _gperl_option_group_get_type
  48 2F 000015B9 _gperl_package_from_type
  49 30 0000137A _gperl_param_spec_package_from_type
  50 31 000016A4 _gperl_param_spec_type_from_package
  51 32 00001154 _gperl_prepend_isa
  52 33 00001203 _gperl_register_boxed
  53 34 0000120D _gperl_register_boxed_alias
  54 35 00001311 _gperl_register_error_domain
  55 36 00001447 _gperl_register_fundamental
  56 37 00001550 _gperl_register_fundamental_alias
  57 38 0000132F _gperl_register_object
  58 39 0000145B _gperl_register_object_alias
  59 3A 000011DB _gperl_register_param_spec
  60 3B 000010EB _gperl_register_sink_func
  61 3C 00001627 _gperl_remove_exception_handler
  62 3D 000012DF _gperl_run_exception_handlers
  63 3E 000013F2 _gperl_set_isa
  64 3F 0000100F _gperl_signal_connect
  65 40 000014F1 _gperl_signal_set_marshaller_for
  66 41 00001028 _gperl_str_eq
  67 42 00001023 _gperl_str_hash
  68 43 00001537 _gperl_sv_copy
  69 44 0000154B _gperl_sv_free
  70 45 00001208 _gperl_sv_from_filename
  71 46 000012B7 _gperl_sv_from_gerror
  72 47 000012B2 _gperl_sv_from_value
  73 48 00001361 _gperl_sv_get_type
  74 49 00001415 _gperl_sv_is_defined
  75 4A 00001668 _gperl_try_convert_enum
  76 4B 0000165E _gperl_try_convert_flag
  77 4C 0000136B _gperl_type_class
  78 4D 00001159 _gperl_type_from_package
  79 4E 000012CB _gperl_value_from_sv
  80 4F 00001186 _newSVGChar
  81 50 0000104B _newSVGParamFlags
  82 51 00001352 _newSVGParamSpec
  83 52 000013AC _newSVGSignalFlags
  84 53 00001410 _newSVGSignalInvocationHint
  85 54 00001398 _newSVGSignalQuery
  86 55 0000166D boot_Glib
  87 56 00001078 gperl_alloc_temp
  88 57 00001429 gperl_argv_free
  89 58 000011F4 gperl_argv_new
  90 59 000015A0 gperl_argv_update
  91 5A 000016AE gperl_boxed_package_from_type
  92 5B 00001055 gperl_boxed_type_from_package
  93 5C 0000105F gperl_callback_destroy
  94 5D 000012A3 gperl_callback_invoke
  95 5E 00001339 gperl_callback_new
  96 5F 00001320 gperl_closure_new
  97 60 000012C1 gperl_closure_new_with_marshaller
  98 61 00001032 gperl_convert_back_enum
  99 62 00001190 gperl_convert_back_enum_pass_unknown
  100 63 0000135C gperl_convert_back_flags
  101 64 0000144C gperl_convert_enum
  102 65 00001384 gperl_convert_flag_one
  103 66 00001587 gperl_convert_flags
  104 67 00001073 gperl_croak_gerror
  105 68 0000116D gperl_default_boxed_wrapper_class
  106 69 0000119A gperl_filename_from_sv
  107 6A 000011EA gperl_format_variable_for_output
  108 6B 000014B0 gperl_fundamental_package_from_type
  109 6C 0000126C gperl_fundamental_type_from_package
  110 6D 000013DE gperl_gerror_from_sv
  111 6E 00001294 gperl_get_boxed_check
  112 6F 00001163 gperl_get_object
  113 70 00001681 gperl_get_object_check
  114 71 000010F0 gperl_handle_logs_for
  115 72 00001393 gperl_install_exception_handler
  116 73 00001366 gperl_new_boxed
  117 74 000014BF gperl_new_boxed_copy
  118 75 00001014 gperl_new_object
  119 76 00001488 gperl_object_check_type
  120 77 000010AA gperl_object_package_from_type
  121 78 0000114F gperl_object_set_no_warn_unreg_subclass
  122 79 00001226 gperl_object_stash_from_type
  123 7A 000016C7 gperl_object_type_from_package
  124 7B 00001677 gperl_option_context_get_type
  125 7C 000016A9 gperl_option_group_get_type
  126 7D 000015B9 gperl_package_from_type
  127 7E 0000137A gperl_param_spec_package_from_type
  128 7F 000016A4 gperl_param_spec_type_from_package
  129 80 00001154 gperl_prepend_isa
  130 81 00001203 gperl_register_boxed
  131 82 0000120D gperl_register_boxed_alias
  132 83 00001311 gperl_register_error_domain
  133 84 00001447 gperl_register_fundamental
  134 85 00001550 gperl_register_fundamental_alias
  135 86 0000132F gperl_register_object
  136 87 0000145B gperl_register_object_alias
  137 88 000011DB gperl_register_param_spec
  138 89 000010EB gperl_register_sink_func
  139 8A 00001627 gperl_remove_exception_handler
  140 8B 000012DF gperl_run_exception_handlers
  141 8C 000013F2 gperl_set_isa
  142 8D 0000100F gperl_signal_connect
  143 8E 000014F1 gperl_signal_set_marshaller_for
  144 8F 00001028 gperl_str_eq
  145 90 00001023 gperl_str_hash
  146 91 00001537 gperl_sv_copy
  147 92 0000154B gperl_sv_free
  148 93 00001208 gperl_sv_from_filename
  149 94 000012B7 gperl_sv_from_gerror
  150 95 000012B2 gperl_sv_from_value
  151 96 00001361 gperl_sv_get_type
  152 97 00001415 gperl_sv_is_defined
  153 98 00001668 gperl_try_convert_enum
  154 99 0000165E gperl_try_convert_flag
  155 9A 0000136B gperl_type_class
  156 9B 00001159 gperl_type_from_package
  157 9C 000012CB gperl_value_from_sv
  158 9D 00001186 newSVGChar
  159 9E 0000104B newSVGParamFlags
  160 9F 00001352 newSVGParamSpec
  161 A0 000013AC newSVGSignalFlags
  162 A1 00001410 newSVGSignalInvocationHint
  163 A2 00001398 newSVGSignalQuery

  Summary

  1000 .data
  5000 .idata
  B000 .rdata
  3000 .reloc
  47000 .text

From @jandubois

On Thu, Dec 18, 2014 at 5​:30 PM, bulk88 via RT
<perlbug-followup@​perl.org> wrote​:

You probably hit the problem I described in https​://rt.perl.org/Ticket/Display.html?id=117001#txn-1197671 where 1 XS DLL links to the exports of another XS DLL, real world example https://metacpan.org/source/JDB/Win32-OLE-0.1712/Makefile.PL#L24 (IDK what modules import those 4 funcs tho, but they are being exported for other XS DLLs to use).

They are used by PerlCtrl (part of the ActiveState Perl Dev Kit), that
wraps a Perl interpreter inside a COM component (so technically not
another XS DLL, but that really doesn't matter).

They are accessed via​:

  HMODULE hModule = GetModuleHandle("OLE");
  if (!hModule)
  return E_FAIL;

  // ...

  m_pCreatePerlObject = GetProcAddress(hModule, "CreatePerlObject");
  m_pSetVariantFromSV = GetProcAddress(hModule, "SetVariantFromSV");
  m_pSetSVFromVariantEx = GetProcAddress(hModule, "SetSVFromVariantEx");

So yes, this code might need to be updated if Perl switches to a
different module naming convention. But it is not a big deal; the code
needs to be adapted to each new Perl release anyways.

Cheers,
-Jan

I know there's a request to:

changing the defult $Config{dlext} on MS Windows from 'dll' to 'xs.dll'

However this seems to have been declined. What remains seems to be a Q&A. I don't see anything actionable here, so I'm closing this case barring further discussion.