develooper Front page | perl.perl5.porters | Postings from April 2018

[perl #133039] ALL_STATIC build is broken on MSVC

Thread Previous
bulk88 via RT
April 2, 2018 01:53
[perl #133039] ALL_STATIC build is broken on MSVC
Message ID:
On Wed, 28 Mar 2018 11:47:17 -0700, randir wrote:
> This is a bug report for perl from,
> generated with the help of perlbug 1.41 running under perl 5.27.11.
> -----------------------------------------------------------------
> [Please describe your issue here]
> link -out:..\..\lib\auto\Storable\Storable.dll -dll -nologo
> -nodefaultlib -debug -opt:ref,icf -ltcg  -libpath:"c
> :\perl\lib\CORE"  -machine:AMD64 Storable.obj
> "..\..\lib\CORE\perl527.lib" oldnames.lib kernel32.lib user32.lib
> gdi32.
> lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib
> oleaut32.lib  netapi32.lib uuid.lib ws2_32.lib mpr.lib
> winmm.lib  version.lib odbc32.lib odbccp32.lib comctl32.lib
> msvcrt.lib vcruntime.lib ucrt.lib -def:Storable.def
> Creating library ..\..\lib\auto\Storable\Storable.lib and object
> ..\..\lib\auto\Storable\Storable.exp
> Storable.obj : error LNK2001: unresolved external symbol
> PL_sv_placeholder
> ..\..\lib\auto\Storable\Storable.dll : fatal error LNK1120: 1
> unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin
> \HostX64\x64\link.EXE"' : return code '0x460'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> This was a VS 2017 build for x64 bit target with BUILD_STATIC and
> ALL_STATIC set to 'define'.

I have this problem also. So far AFAIK the problem is work, made 

 sub depend {
+    my $extra_deps = "";
+    unless ($ENV{PERL_CORE}) {
+        # needs arch/lib
+        $extra_deps = '';
+    }
-stacksize: Makefile \$(LINKEXT)
+lib/Storable/ : \$(INST_DYNAMIC)$extra_deps
 	\$(PERLRUNINST) stacksize

made depend on a 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, 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 func
 tion 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.

bulk88 ~ bulk88 at

via perlbug:  queue: perl5 status: new

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About