Skip to content
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

[PATCH] for perl static build for gcc+win32 #16469

Closed
p5pRT opened this issue Mar 17, 2018 · 28 comments
Closed

[PATCH] for perl static build for gcc+win32 #16469

p5pRT opened this issue Mar 17, 2018 · 28 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Mar 17, 2018

Migrated from rt.perl.org#132992 (status was 'resolved')

Searchable as RT132992$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 17, 2018

From Vadim.Konovalov@dell.com

Created by vadim.konovalov@dell.com

I happen to do​:

gmake -f GNUmakefile ALL_STATIC=define
(C++ and gmake is the one that comes with strawberry)

I get this error​:
C​:\vad\perl-dev\perl-compile\perl-5.27.9-0\miniperl.exe "-I..\..\lib" -MExtUtils​::Command -e chmod -- 755 ..\..\lib\auto\Unicode\Collate\Collate.a
gmake[1]​: Leaving directory 'C​:/vad/perl-dev/perl-compile/perl-5.27.9-0/cpan/Unicode-Collate'
Making header files for XS...
Unicode​::Normalize, mkheader​: CombiningClass.pl not found at ./mkheader line 67.
  require ./mkheader called at Makefile.PL line 11
Unsuccessful Makefile.PL(dist/Unicode-Normalize)​: code=512 at ..\make_ext.pl line 518.
gmake.EXE​: *** [GNUmakefile​:1584​: Extensions_static] Error 2

.\dist\Unicode-Normalize\mkheader expects for the
File CombiningClass.pl to exist, yet it is generated on Extensions_normalize
stage, IOW should be here during "Extensions" phase;

Next, "ALL_STATIC" means "BUILD_STATIC", so I've edited it to be so.

Therefore I think the attached edit looks proper.

TIA,
Vadim

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.27.9:

Configured by konovv at Tue Feb 27 18:23:50 2018.

Summary of my perl5 (revision 5 version 27 subversion 9) configuration:

  Platform:
    osname=MSWin32
    osvers=10.0.14393
    archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended
    useposix=true
    d_sigaction=undef
    useithreads=define
    usemultiplicity=define
    use64bitint=undef
    use64bitall=undef
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='gcc'
    ccflags =' -s -O2 -DWIN32  -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields'
    optimize='-s -O2'
    cppflags='-DWIN32'
    ccversion=''
    gccversion='7.1.0'
    gccosandvers=''
    intsize=4
    longsize=4
    ptrsize=4
    doublesize=8
    byteorder=1234
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=12
    longdblkind=3
    ivtype='long'
    ivsize=4
    nvtype='double'
    nvsize=8
    Off_t='long long'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='g++'
    ldflags ='-s -L"c:\perl\lib\CORE" -L"C:\MinGW\lib"'
    libpth=C:\MinGW\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=libperl527.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs
    dlext=dll
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags=' '
    lddlflags='-mdll -s -L"c:\perl\lib\CORE" -L"C:\MinGW\lib"'



@INC for perl 5.27.9:
    C:\Work\PerlScripts\utl
    C:\Work\PerlScripts\mfdev
    C:\Personal\perlutl
    C:/vad/perl-dev/perl-compile/perl-5.27.9/lib


Environment for perl 5.27.9:
    HOME=c:\apps
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\Program Files\Haskell\bin;C:\apps\Haskell-p-8.2.2\lib\extralibs\bin;C:\apps\Haskell-p-8.2.2\bin;C:\apps\vim80.1157;C:\apps\perl-5.26.0-32\c\bin;C:\apps\perl-5.26.0-32\perl\site\bin;C:\apps\perl-5.26.0-32\perl\bin;C:\apps\tcl-866-as86\bin;C:\apps\Python27;C:\apps\clisp-2.49;C:\Work\apps\report;C:\Work\apps;C:\apps\pandoc;C:\apps\emacs\bin;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\EMC\;c:\sh;C:\Program Files\Dell\Dell Data Protection\Encryption\;C:\apps\ggobi;C:\apps\Haskell-p-8.2.2\mingw\bin;C:\Users\konovv\AppData\Roaming\cabal\bin;C:\apps\haskell-p-8.2.2\Roaming\local\bin;C:\Users\konovv\.cargo\bin;C:\Users\konovv\AppData\Local\Microsoft\WindowsApps;C:\rakudo\bin;C:\rakudo\share\perl6\site\bin
    PERL5LIB=C:\Work\PerlScripts\utl;C:\Work\PerlScripts\mfdev;C:\Personal\perlutl
    PERL_BADLANG (unset)
    SHELL (unset)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 17, 2018

From Vadim.Konovalov@dell.com

Inline Patch
diff -rbu perl-5.27.9-orig/win32/GNUmakefile perl-5.27.9-32/win32/GNUmakefile
--- perl-5.27.9-orig/win32/GNUmakefile	2018-02-17 14:10:52.000000000 +0300
+++ perl-5.27.9-32/win32/GNUmakefile	2018-03-10 23:49:56.252280400 +0300
@@ -232,10 +232,11 @@
 
 #
 # in addition to BUILD_STATIC the option ALL_STATIC makes *every*
-# extension get statically built
+# extension get statically built.
 # This will result in a very large perl executable, but the main purpose
 # is to have proper linking set so as to be able to create miscellaneous
-# executables with different built-in extensions
+# executables with different built-in extensions.
+# Using ALL_STATIC automatically turns on BUILD_STATIC.
 #
 #ALL_STATIC	:= define
 
@@ -875,14 +876,11 @@
 GLOBEXE		= ..\perlglob.exe
 CONFIGPM	= ..\lib\Config.pm
 GENUUDMAP	= ..\generate_uudmap.exe
-ifeq ($(BUILD_STATIC),define)
-PERLSTATIC	= static
-else
 ifeq ($(ALL_STATIC),define)
-PERLSTATIC	= static
-else
-PERLSTATIC	=
+BUILD_STATIC	= define
 endif
+ifeq ($(BUILD_STATIC),define)
+PERLSTATIC	= static
 endif
 
 # Unicode data files generated by mktables
@@ -1497,7 +1495,7 @@
 ifeq ($(CCTYPE),GCC)
 	$(LIB32) $(LIB_FLAGS) $@ $(PERLDLL_OBJ)
 	if exist $(STATICDIR) rmdir /s /q $(STATICDIR)
-	for %%i in ($(shell type Extensions_static)) do \
+	for %%i in ($(shell ..\perl -MConfig -we 'print map {m|([^/]+)$$|; "../lib/auto/$$_/$$1$$Config{_a} "} split " ",$$Config{static_ext}')) do \
 		@mkdir $(STATICDIR) && cd $(STATICDIR) && \
 		$(ARCHPREFIX)ar x ..\%%i && \
 		$(ARCHPREFIX)ar q ..\$@ *$(o) && \
@@ -1559,7 +1557,9 @@
 $(PERLEXESTATIC): $(PERLSTATICLIB) $(CONFIGPM) $(PERLEXEST_OBJ) $(PERLEXE_RES)
 ifeq ($(CCTYPE),GCC)
 	$(LINK32) -mconsole -o $@ $(BLINK_FLAGS) \
-	    $(PERLEXEST_OBJ) $(PERLEXE_RES) $(PERLSTATICLIB) $(LIBFILES)
+	    $(PERLEXEST_OBJ) $(PERLEXE_RES) $(PERLSTATICLIB) $(shell type Extensions_static) \
+	    $(LIBFILES)
+	    
 else
 	$(LINK32) -out:$@ $(BLINK_FLAGS) \
 	    $(PERLEXEST_OBJ) $(PERLEXE_RES) $(PERLSTATICLIB) $(LIBFILES) $(SETARGV_OBJ)
@@ -1610,7 +1610,7 @@
 # be running in parallel like UNIDATAFILES, this target a placeholder for the
 # future
 ifeq ($(BUILD_STATIC),define)
-rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE) $(PERLEXESTATIC)
+rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)
 else
 rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE)
 endif
diff -rbu perl-5.27.9-orig/win32/list_static_libs.pl perl-5.27.9-32/win32/list_static_libs.pl
--- perl-5.27.9-orig/win32/list_static_libs.pl	2018-02-17 14:10:52.000000000 +0300
+++ perl-5.27.9-32/win32/list_static_libs.pl	2018-03-10 23:42:10.438127100 +0300
@@ -7,11 +7,11 @@
 
 my @statics = split /\s+/, $Config{static_ext};
 
-my %extralibs;
+my (@extralibs, %extralibs); # collect extralibs, preserving their order
 for (@statics) {
     my $file = "..\\lib\\auto\\$_\\extralibs.ld";
     open my $fh, '<', $file or die "can't open $file for reading: $!";
-    $extralibs{$_}++ for grep {/\S/} split /\s+/, join '', <$fh>;
+    push @extralibs, grep {++$extralibs{$_}==1 ? $_ : ()} grep {/\S/} split /\s+/, join '', <$fh>;
 }
 print map {s|/|\\|g;m|([^\\]+)$|;"..\\lib\\auto\\$_\\$1$Config{_a} "} @statics;
-print map {"$_ "} sort keys %extralibs;
+print map {"$_ "} @extralibs;

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 19, 2018

From Vadim.Konovalov@dell.com

Here it is

On 03/14/2018 02​:32 AM, Konovalov, Vadim wrote​:

I need this patch to be merged, after that I will be happy to work on
further improvements on the matter.

Should I do push request instead, or perl bug ticket ?

bug ticket.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

I can confirm that static build currently fails when done using mingw. But there's another makefile which is also used when building with mingw, win32/makefile.mk, though it's used with dmake, not gmake.

And for me, to make dmake-based all-static build work, the only required change was​:

Inline Patch
diff --git a/win32/makefile.mk b/win32/makefile.mk
index 80bd6e8544..d82ec57819 100644
--- a/win32/makefile.mk
+++ b/win32/makefile.mk
@@ -1542,7 +1542,7 @@ Extensions_realclean :
 # be running in parallel like UNIDATAFILES, this target a placeholder for the
 # future
 .IF "$(BUILD_STATIC)"=="define"
-rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE) $(PERLEXESTATIC)
+rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)
 .ELSE
 rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE)
 .ENDIF


I suppose that the same applies to gmake-based builds.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From Vadim.Konovalov@dell.com

I can confirm that static build currently fails when done
using mingw. But there's another makefile which is also
used when building with mingw, win32/makefile.mk, though
it's used with dmake, not gmake.

And for me, to make
dmake-based all-static build work, the only required change
was​:

diff --git a/win32/makefile.mk b/win32/makefile.mk
index 80bd6e8544..d82ec57819 100644
--- a/win32/makefile.mk
+++ b/win32/makefile.mk
@​@​ -1542,7 +1542,7 @​@​
Extensions_realclean :
# be running in parallel like
UNIDATAFILES, this target a placeholder for the # future
.IF "$(BUILD_STATIC)"=="define"
-rebasePE : Extensions
$(PERLDLL) Extensions_normalize $(PERLEXE) $(PERLEXESTATIC)
+rebasePE : Extensions_normalize Extensions $(PERLDLL)
$(PERLEXE)
+$(PERLEXESTATIC)
.ELSE
rebasePE : Extensions
$(PERLDLL) Extensions_normalize $(PERLEXE) .ENDIF

thanks

This is correct - to fix the build - all is needed to do - place Extensions_normalize sooner in the chain;

In addition, my patch makes 'ALL_STATIC' to have also 'BUILD_STATIC', and yet fixes an error in helper script
win32\list_static_libs.pl

all in all, seems reasonable update even at 5.27.9, but 5.27.10 also good for it :)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

On Tue, 27 Mar 2018 22​:53​:19 -0700, Vadim.Konovalov@​dell.com wrote​:

and yet fixes an error in helper script
win32\list_static_libs.pl

What is the error there? How can I check that it was present before your patch and is absent after applying it?

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From Vadim.Konovalov@dell.com

Vadim.Konovalov wrote​:

and yet fixes an error in
helper script win32\list_static_libs.pl

What is the error
there? How can I check that it was present before your
patch and is absent after applying it?

The incorrect thing there is that objects are "sort"-ed, but there is no actual reason for them to be sorted;

In simple cases - things work

In more complicated cases - when order is significant - linker error happens there, sometimes;

actually order should be preserved;

PS; it was me who introduced that file. Why I placed the 'sort' there, or was it even me - IDK; :)​:)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @bulk88

On Wed, 28 Mar 2018 05​:46​:10 -0700, Vadim.Konovalov@​dell.com wrote​:

The incorrect thing there is that objects are "sort"-ed, but there is
no actual reason for them to be sorted;

In simple cases - things work

In more complicated cases - when order is significant - linker error
happens there, sometimes;

actually order should be preserved;

PS; it was me who introduced that file. Why I placed the 'sort' there,
or was it even me - IDK; :)​:)

I agree, left to right ordering of deps has no meaning for a makefile. Usually a maketool, on a NON-PARALLEL build will build from left to right. But during parallel building any dep is fair game to execute at any time if the tree says all sub-deps r completed. Testing each target individually is the only way to prove the dep tree works for it and parallelness also will work. Personally I suggest (and have done this before when editing those Win32 makefiles) putting longer running deps on the left so more cores have more work to do. So if there are 4 deps, one 10 minutes, and 3 2 minutes deps and 1 5 minute, lets call them A10, B2, C2, D2, E5. On a 2 core machine, you want the maketool to do

Core 1 A10 = 10 mins
Core 2 E5 B2 C2 D2 = 11 mins

not

Core 1 E5 A10 = 15 mins
Core 2 B2 C2 D2 = 6 mins

If changing the left to order fixes something, it means there is a bug in the dep tree and the 2 deps that are written as siblings, 1 is parent and 1 is the child in reality and the MKF needs to be restructured to reflect that (or build products changed to not depend on each other, more parallelness).

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From Vadim.Konovalov@dell.com

On Wed, 28 Mar 2018 05​:46​:10 -0700,
Vadim.Konovalov wrote​:

The incorrect thing there is that objects are "sort"-ed, but there is no actual
reason for them to be sorted;

In simple cases - things work
...
I agree, left to right
ordering of deps has no meaning for a makefile. Usually a

At the mentioned by me place 'sort' was not on dependencies, rather it was part of " list_static_libs.pl"
The wrong thing there was to re-sort linker 's arguments;

On the other hand, at this makefile goal​:

rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)

Extensions_normalize should be satisfied before - all other extensions;

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

I've split the original patch into a series of four which can be applied independently. I've tested them all using a dmake-based mingw toolchain.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

0001-Fix-static-builds-with-MinGW.patch
From 60915860b161b84edac990681f0adc7d8de46233 Mon Sep 17 00:00:00 2001
From: Sergey Aleynikov <sergey.aleynikov@gmail.com>
Date: Wed, 28 Mar 2018 22:35:05 +0300
Subject: [PATCH 1/4] Fix static builds with MinGW

Move Extensions_normalize target before Extensions
target to satisfy dependencies.
---
 win32/GNUmakefile | 2 +-
 win32/makefile.mk | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/win32/GNUmakefile b/win32/GNUmakefile
index 7e464fa3cb..5c28731c49 100644
--- a/win32/GNUmakefile
+++ b/win32/GNUmakefile
@@ -1610,7 +1610,7 @@ PostExt : ..\lib\Storable\Limit.pm
 # be running in parallel like UNIDATAFILES, this target a placeholder for the
 # future
 ifeq ($(BUILD_STATIC),define)
-rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE) $(PERLEXESTATIC)
+rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)
 else
 rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE)
 endif
diff --git a/win32/makefile.mk b/win32/makefile.mk
index 80bd6e8544..ba9c5bf5c0 100644
--- a/win32/makefile.mk
+++ b/win32/makefile.mk
@@ -1542,7 +1542,7 @@ Extensions_realclean :
 # be running in parallel like UNIDATAFILES, this target a placeholder for the
 # future
 .IF "$(BUILD_STATIC)"=="define"
-rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE) $(PERLEXESTATIC)
+rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)
 .ELSE
 rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE)
 .ENDIF
-- 
2.16.1.windows.4

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

0002-Fix-spelling-in-windows-makefiles.patch
From 94fdafacfb9d2ee4590b5390b9aac91bb936f844 Mon Sep 17 00:00:00 2001
From: Sergey Aleynikov <sergey.aleynikov@gmail.com>
Date: Wed, 28 Mar 2018 23:26:20 +0300
Subject: [PATCH 2/4] Fix spelling in windows makefiles

---
 win32/GNUmakefile | 4 ++--
 win32/Makefile    | 4 ++--
 win32/makefile.mk | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/win32/GNUmakefile b/win32/GNUmakefile
index 5c28731c49..c1d4ac63a5 100644
--- a/win32/GNUmakefile
+++ b/win32/GNUmakefile
@@ -232,10 +232,10 @@ DEFAULT_INC_EXCLUDES_DOT := define
 
 #
 # in addition to BUILD_STATIC the option ALL_STATIC makes *every*
-# extension get statically built
+# extension get statically built.
 # This will result in a very large perl executable, but the main purpose
 # is to have proper linking set so as to be able to create miscellaneous
-# executables with different built-in extensions
+# executables with different built-in extensions.
 #
 #ALL_STATIC	:= define
 
diff --git a/win32/Makefile b/win32/Makefile
index 83369d2054..eff48e1d32 100644
--- a/win32/Makefile
+++ b/win32/Makefile
@@ -199,10 +199,10 @@ CCTYPE		= MSVC60
 
 #
 # in addition to BUILD_STATIC the option ALL_STATIC makes *every*
-# extension get statically built
+# extension get statically built.
 # This will result in a very large perl executable, but the main purpose
 # is to have proper linking set so as to be able to create miscellaneous
-# executables with different built-in extensions
+# executables with different built-in extensions.
 #
 #ALL_STATIC	= define
 
diff --git a/win32/makefile.mk b/win32/makefile.mk
index ba9c5bf5c0..053a934746 100644
--- a/win32/makefile.mk
+++ b/win32/makefile.mk
@@ -227,10 +227,10 @@ DEFAULT_INC_EXCLUDES_DOT *= define
 
 #
 # in addition to BUILD_STATIC the option ALL_STATIC makes *every*
-# extension get statically built
+# extension get statically built.
 # This will result in a very large perl executable, but the main purpose
 # is to have proper linking set so as to be able to create miscellaneous
-# executables with different built-in extensions
+# executables with different built-in extensions.
 #
 #ALL_STATIC	*= define
 
-- 
2.16.1.windows.4

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

0003-Fix-ALL_STATIC-builds-with-MinGW.patch
From 81551f7b954d9764af3b9ab060ff141a6ea3c387 Mon Sep 17 00:00:00 2001
From: Sergey Aleynikov <sergey.aleynikov@gmail.com>
Date: Wed, 28 Mar 2018 23:28:56 +0300
Subject: [PATCH 3/4] Fix ALL_STATIC builds with MinGW

ALL_STATIC required BUILD_STATIC set but that was not documented.
---
 win32/GNUmakefile | 4 ++--
 win32/makefile.mk | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/win32/GNUmakefile b/win32/GNUmakefile
index c1d4ac63a5..1704126816 100644
--- a/win32/GNUmakefile
+++ b/win32/GNUmakefile
@@ -235,7 +235,7 @@ DEFAULT_INC_EXCLUDES_DOT := define
 # extension get statically built.
 # This will result in a very large perl executable, but the main purpose
 # is to have proper linking set so as to be able to create miscellaneous
-# executables with different built-in extensions.
+# executables with different built-in extensions. It implies BUILD_STATIC.
 #
 #ALL_STATIC	:= define
 
@@ -1609,7 +1609,7 @@ PostExt : ..\lib\Storable\Limit.pm
 # all PE files need to be built by the time this target runs, PP files can still
 # be running in parallel like UNIDATAFILES, this target a placeholder for the
 # future
-ifeq ($(BUILD_STATIC),define)
+ifeq ($(PERLSTATIC),static)
 rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)
 else
 rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE)
diff --git a/win32/makefile.mk b/win32/makefile.mk
index 053a934746..ed250c720e 100644
--- a/win32/makefile.mk
+++ b/win32/makefile.mk
@@ -230,7 +230,7 @@ DEFAULT_INC_EXCLUDES_DOT *= define
 # extension get statically built.
 # This will result in a very large perl executable, but the main purpose
 # is to have proper linking set so as to be able to create miscellaneous
-# executables with different built-in extensions.
+# executables with different built-in extensions. It implies BUILD_STATIC.
 #
 #ALL_STATIC	*= define
 
@@ -1541,7 +1541,7 @@ Extensions_realclean :
 # all PE files need to be built by the time this target runs, PP files can still
 # be running in parallel like UNIDATAFILES, this target a placeholder for the
 # future
-.IF "$(BUILD_STATIC)"=="define"
+.IF "$(PERLSTATIC)"=="static"
 rebasePE : Extensions_normalize Extensions $(PERLDLL) $(PERLEXE) $(PERLEXESTATIC)
 .ELSE
 rebasePE : Extensions $(PERLDLL) Extensions_normalize $(PERLEXE)
-- 
2.16.1.windows.4

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 28, 2018

From @dur-randir

0004-Maintain-extralibs-order-for-linker.patch
From 7cffb760e2744e69439c3e0f34f5721b2fcf8d2d Mon Sep 17 00:00:00 2001
From: Sergey Aleynikov <sergey.aleynikov@gmail.com>
Date: Wed, 28 Mar 2018 23:53:32 +0300
Subject: [PATCH 4/4] Maintain extralibs order for linker

As per discussion in RT # 132992
---
 win32/list_static_libs.pl | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/win32/list_static_libs.pl b/win32/list_static_libs.pl
index 4b63d90812..a86eea5273 100644
--- a/win32/list_static_libs.pl
+++ b/win32/list_static_libs.pl
@@ -7,11 +7,11 @@ use Config;
 
 my @statics = split /\s+/, $Config{static_ext};
 
-my %extralibs;
+my (@extralibs, %extralibs); # collect extralibs, preserving their order
 for (@statics) {
     my $file = "..\\lib\\auto\\$_\\extralibs.ld";
     open my $fh, '<', $file or die "can't open $file for reading: $!";
-    $extralibs{$_}++ for grep {/\S/} split /\s+/, join '', <$fh>;
+    push @extralibs, grep {!$extralibs{$_}++} grep {/\S/} split /\s+/, join '', <$fh>;
 }
 print map {s|/|\\|g;m|([^\\]+)$|;"..\\lib\\auto\\$_\\$1$Config{_a} "} @statics;
-print map {"$_ "} sort keys %extralibs;
+print map {"$_ "} @extralibs;
-- 
2.16.1.windows.4

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From Vadim.Konovalov@dell.com

I've split the original patch into a series of four which
can be applied independently. I've tested them all using a
dmake-based mingw toolchain.

Nice approach to chew the food in smaller pieces :)
Thanks :)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From @khwilliamson

On 03/28/2018 03​:00 PM, Sergey Aleynikov via RT wrote​:

I've split the original patch into a series of four which can be applied independently. I've tested them all using a dmake-based mingw toolchain.

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132992

Thanks, applied as
9999704..122ce0a

Can this ticket be closed?

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From Vadim.Konovalov@dell.com

Can this ticket be closed?
Yes, I think so

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From @bulk88

On Thu, 29 Mar 2018 07​:56​:39 -0700, public@​khwilliamson.com wrote​:

On 03/28/2018 03​:00 PM, Sergey Aleynikov via RT wrote​:

I've split the original patch into a series of four which can be
applied independently. I've tested them all using a dmake-based mingw
toolchain.

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132992

Thanks, applied as
9999704..122ce0a

Can this ticket be closed?

I wouldn't have applied this. Left to right order can't be depended on.

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From Vadim.Konovalov@dell.com

Can this ticket be closed?
I wouldn't have applied this. Left to right order can't be depended on.

This is a bug in GNUmakefile, (and also there is another bug, which I mentioned
recently but no-one replied me, under intentionally stupid subject "Bug in perl, yet another one")
https://www.nntp.perl.org/group/perl.perl5.porters/2018/03/msg249959.html

PATCH are good in a sense that they do not improve situation but it also does not do it worse.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From @khwilliamson

On 03/29/2018 09​:51 AM, Konovalov, Vadim wrote​:

Can this ticket be closed?
I wouldn't have applied this. Left to right order can't be depended on.

This is a bug in GNUmakefile, (and also there is another bug, which I mentioned
recently but no-one replied me, under intentionally stupid subject "Bug in perl, yet another one")
https://www.nntp.perl.org/group/perl.perl5.porters/2018/03/msg249959.html

PATCH are good in a sense that they do not improve situation but it also does not do it worse.

Don't you mean that they DO improve the situation?

Back when I had to deal with these kinds of things, on a 16-bit Unix
box, we used the tsort command to order libraries. I see that my Linux
box still has that command.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From @bulk88

There are multiple bugs here, or design problems. Normalize is a separate target because it is very long to build because of $(UNIDATAFILES)/mktables. Extensions_normalize isn't a dep of Extensions_static. So list_static_libs.pl script errors out if normalize isn't built yet by time of list_static_libs.pl executing, either because its excluded by my attempted mayb wrong fix of " --static !Unicode/Normalize" or because BY CHANCE DLL Extensions_normalize hasn't built yet which indirectly built $(UNIDATAFILES) but it will later be rebuilt as static by Extensions_static target (bug in itself if it happens). Making Extensions_normalize a dep of Extensions_static would break the regular DLL build. Also Extensions_normalize needs a --static flag on static builds not dynamic to generate static .libs not DLLs.

Im tempted to make a Extensions_normalize_dyn and Extensions_normalize_static target, and split Extensions_static into targets, parent (make_ext.pl) child (list_static_libs.pl) and child depends on the mega-build-everything make_ext.pl static target and the other Extensions_normalize_static target. That allows paralleling but all static build products feed in together. I've played with the MKF a bit but I am trying to avoid a "ifeq ($(ALL_STATIC),define)" near Extensions_static but I think thats the only way to control if Normalize is dyn or static. and which bigger target it feeds into.

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 29, 2018

From Vadim.Konovalov@dell.com

From​: Karl Williamson

From​: Vadim
PATCH are good in a sense that they do not improve situation
but it also does not do it worse.
Don't you mean that they DO improve the
situation?

Bulk88 has concern that reordering of dependancies in makefile goal is not a correct way of fixing things, and explains this point by thinking about parallel build

From this POV - there was a bug, and there is a bug in case of parallel build;

Still, his concern could be addressed later then, I would not mind another separate bug ticket for this.

There is little point of not accepting improvement patches, which incrementally improve the satiation, by arguing that there is another bug nearby

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 30, 2018

From Vadim.Konovalov@dell.com

From​: Karl Williamson

From​: Vadim
PATCH are good
in a sense that they do not improve situation but it

also does not do it worse.

Don't you mean that they DO
improve the situation?

Bulk88 has concern that reordering
of dependancies in makefile goal is not a correct way of
fixing things, and explains this point by thinking about
parallel build

From this POV - there was a bug, and there
is a bug in case of parallel build;

IOW a person who introduced "Extensions_normalise" introduced a bug for parallelized build;

Still, his concern
could be addressed later then, I would not mind another
separate bug ticket for this.

There is little point of not
accepting improvement patches, which incrementally improve
the satiation, by arguing that there is another bug nearby

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 9, 2018

From @bulk88

I think this ticket can now be closed since the patches in it, that were applied, that I found issues with, were fixed in https://perl5.git.perl.org/perl.git/commit/908f2cb56527d29c9176e478fa7eee0d02a7c77e

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 11, 2018

@xsawyerx - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jun 23, 2018

From @khwilliamson

Thank 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
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jun 23, 2018

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant