[x64 Strawberry] DynaLoader needs stripped dll's

Hi,

(I'm assuming this is not one of those "just me" situations - and that 
others will be able to reproduce this. But I don't yet know that to be the 
case.)

Under normal conditions, there's actually no visible problems. Strawberry's 
lddlflags includes the -s (--strip-all) switch, and everything is fine. But 
DynaLoader might go nuts if it has to load perl dll's that were built 
without that "-s" switch in place.

As a demo, anyone with x64 Strawberry might like to remove the "-s" in the
lddlflags entry in lib/Config_heavy.pl and then run this Inline::C script:

##############################
use warnings;
use Inline C => Config =>
    FORCE_BUILD => 1,
    BUILD_NOISY => 1;

use Inline C => <<'EOC';
void greet() {
     printf("Hello World\n");
}

EOC
use Inline C => <<'EOC2';
void regreet() {
     printf("Hello World Again\n");
}

EOC2

greet();
regreet();

##############################

It should compile ok, but then produce something like the following nonsense 
at runtime:

##############################
Had problems bootstrapping Inline module 'try_pl_18bd6'

Can't load
'C:\_32\pscrpt\inline\_Inline\lib/auto/try_pl_18bd6/try_pl_18bd6.dll' for
module try_pl_18bd6: load_file:%1 is not a valid Win32 application at
C:/_64/strawberry512/perl/lib/DynaLoader.pm line 200.
 at C:/_64/strawberry512/perl/site/lib/Inline.pm line 534

 at try.pl line 14
BEGIN failed--compilation aborted at try.pl line 20.
##############################

Then re-instate the "-s" flag in lddlflags, re-run the above script, and 
watch it run perfectly well.

It has been put to me that it doesn't make much sense that DynaLoader's 
loading capability relies on the dll's having been built with the "-s" 
switch - and that's my question. How is it that the '-s' switch is having 
such a far reaching effect ? Does it signify some problem in the way 
DynaLoader works ? Does it signify a bug in gcc itself ? Or is there a good 
reason that DynaLoader should fail in this way when the -s switch is removed 
?

There is, in fact, nothing wrong with the dll that DynaLoader claims is "not 
a valid Win32 application". It's the loading of the first dll that prevents 
the second dll from loading. (Don't load that first dll, and the second dll 
will load fine. The problem only seems to arise with the loading of multiple 
dll's.)

My perl -V is attached. (You'll see that the -s is missing from lddlflags as 
I created that file at a time when I had removed the -s switch. Normally, of 
course, the -s would be present).

I'm runing Windows Vista 64.

Strawberry uses the MinGW64 port of gcc-4.4.3, and I've struck the same 
problem with the MinGW64 port of gcc-4.6.0 (cross-compiler).

I've also struck the same issue with mingw32.org's port of gcc-3.4.5 and x86 
perls (5.6.2, 5.8.8, 5.8.9, 5.10.0, 5.12.2), but not with the particular 
script presented above. In the case of gcc-3.4.5, it's only when I build 
Math::MPFI that I need to have the -s switch in place. If Math::MPFI gets 
built with the -s switch missing I get that same bizarre runtime error from 
DynaLoader when it tries to load auto/Math/MPFI/MPFI.dll.
Math::MPFI has quite a long dependency chain, and therefore doesn't make a 
very good demo - which is the reason that I've presented the above demo, 
instead.

Hope someone can make sense of the behaviour .... and the above account ;-)

Cheers,
Rob

• [x64 Strawberry] DynaLoader needs stripped dll's by Sisyphus