New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ALL_STATIC build is broken on MSVC #16484
Comments
From @dur-randirCreated by @dur-randir link -out:..\..\lib\auto\Storable\Storable.dll -dll -nologo This was a VS 2017 build for x64 bit target with BUILD_STATIC and Perl Info
|
From @bulk88On Wed, 28 Mar 2018 11:47:17 -0700, randir wrote:
I have this problem also. So far AFAIK the problem is https://rt.perl.org/Public/Bug/Display.html?id=127743 work, made sub depend { https://perl5.git.perl.org/perl.git/commitdiff/c0e3b4b51cabf15ed8fc5f564dfeea31c25f5239 made Limit.pm depend on a Storable.so/Storable.dll file, which is now being built while none of the other modules build .dlls, they only build a "extralibs.ld" and "Foo.lib" file because this is a static perl, not shared lib perl. Because of EUMM::MM_Win32.pm, in the storable makefile, EUMM adds -DPERLDLL to CCFLAGS/CC cmd line if its "static" perl, but that causes the VC CC to assume all global data vars are INSIDE the same .dll, and generate such machine code, but we are building Storable as a DLL on static perl, and because of Win32 PE/binary arch details, global DATA vars have different machine code on if they are inside the same DLL (load register with data at abs constant pointer to inside same DLL aka var = *(int*)0x1234) vs an external DLL (load register with pointer from absolute pointer to inside same DLL (read import table), load register from pointer loaded in register aka var = **(int**)0x1234), so it doesn't link. Win32 C functions, if they aren't aware the function call is outside the same DLL (no declspec dllimport prototype), the CC/linker will link them to to mini jump stub functions that leave the same DLL to another DLL. The jump stubs also allow const function pointers to exist to C functions from other DLL. THe CC takes addr of the jump stub inside the same DLL, not the func ptr in the import table pointing to another DLL at a random other address in the process. If I remove the -DPERLDLL by hand from the storable makefile, I can compile a storable.dll on static perl. Removing PERLDLL probably isn't the solution since then you will probably break compiling the static perl and the storable.a/storable.lib that goes inside the static perl binary. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Sun, 01 Apr 2018 18:53:00 -0700, bulk88 wrote:
Does this patch fix the problem? It did for me when I reproduced the PL_sv_placeholder link failure. -- |
From @bulk880001-RT-133039-dont-build-a-Storable.so-.dll-with-a-stati.patchFrom 22e31f20734ef552f2ca625d0e173c0e13eaaa7c Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Mon, 2 Apr 2018 10:49:54 -0400
Subject: [PATCH] RT #133039 dont build a Storable.so/.dll with a static perl
build
All static perls aren't capable of making shared libs that will never
execute anyways. Commit c0e3b4b51c make Limit.pm depend on Storable.so/.dll
which isnt supposed to exist in a static build but the EUMM makefile still
has enough logic/targets defined that "dynamic ext on static perl" will
probably generate a disk file to satisfy that target (execution is another
story). Except on Win32, where global data vars must be declared in C if
they are stored inside or outside the DLL where the reference will be made.
PL_sv_placeholder is one such var. On no-threads static win32 Perl I assume
even more breakage and missing symbol warnings.
Fix the problem by making sure the .a/.lib and perlstatic.exe or .so/.dll
are built respectfully before running stacksize.pl.
I also noticed dist/Storable/lib was untracked and unignored, so put it
on ignore list because it is a build product.
See more details in #133039.
Related to RT #127743
---
dist/Storable/.gitignore | 1 +
dist/Storable/Makefile.PL | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/dist/Storable/.gitignore b/dist/Storable/.gitignore
index acf5f9a..de731b9 100644
--- a/dist/Storable/.gitignore
+++ b/dist/Storable/.gitignore
@@ -1 +1,2 @@
/Storable.pm
+/lib
diff --git a/dist/Storable/Makefile.PL b/dist/Storable/Makefile.PL
index 4e9c650..ed53816 100644
--- a/dist/Storable/Makefile.PL
+++ b/dist/Storable/Makefile.PL
@@ -43,7 +43,7 @@ WriteMakefile(
},
) : ()),
dist => { SUFFIX => 'gz', COMPRESS => 'gzip -f' },
- clean => { FILES => 'Storable-* Storable.pm lib/Storable/Limit.pm' },
+ clean => { FILES => 'Storable-* Storable.pm lib' },
);
# Unlink the .pm file included with the distribution
@@ -89,9 +89,10 @@ sub depend {
# blib.pm needs arch/lib
$extra_deps = ' Storable.pm';
}
+ my $linktype = uc($_[0]->{LINKTYPE});
my $limit_pm = File::Spec->catfile('lib', 'Storable', 'Limit.pm');
"
-$limit_pm : stacksize \$(INST_DYNAMIC)$extra_deps
+$limit_pm : stacksize \$(INST_$linktype)$extra_deps
\$(MKPATH) \$(INST_LIB)
\$(FULLPERLRUNINST) stacksize $options
--
2.5.0.windows.1
|
From @dur-randirOn Mon, 02 Apr 2018 08:09:16 -0700, bulk88 wrote:
Yes, it fixed it for me too. |
From @tonycozOn Mon, 02 Apr 2018 08:09:16 -0700, bulk88 wrote:
Fixed it for me, thanks, applied as f4e3105. Tony |
@tonycoz - Status changed from 'open' to 'pending release' |
From @bulk88Some details I forgot to post, for historical reasons. BEFORE Generating a gmake-style Makefile C:\perl521\srcnew\miniperl.exe "-I..\..\lib" -MExtUtils::Command -e chmod -- 755 AFTER Generating a gmake-style Makefile C:\perl521\srcnew\miniperl.exe "-I..\..\lib" -MExtUtils::Command -e chmod -- 755 |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#133039 (status was 'resolved')
Searchable as RT133039$
The text was updated successfully, but these errors were encountered: