Skip Menu |
Report information
Id: 132992
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: Vadim.Konovalov [at] dell.com
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: medium
Type:
Perl Version: 5.27.9
Fixed In: (no value)



To: "perlbug [...] perl.org" <perlbug [...] perl.org>
Subject: [PATCH] for perl static build for gcc+win32
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Date: Sat, 17 Mar 2018 13:21:05 +0000
Download (untitled) / with headers
text/plain 4.5k

 

This is a bug report for perl from vadim.konovalov@dell.com,

generated with the help of perlbug 1.41 running under perl 5.27.9.

 

 

-----------------------------------------------------------------

[Please describe your issue here]

 

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

 

 

[Please do not change anything below this line]

-----------------------------------------------------------------

---

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)

Message body is not shown because sender requested not to inline it.

To: James E Keenan <jkeenan [...] pobox.com>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Subject: [perl #132992] RE: I found bug in perl 5.27.9
Date: Mon, 19 Mar 2018 12:01:43 +0000
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Download (untitled) / with headers
text/plain 244b
Here it is On 03/14/2018 02:32 AM, Konovalov, Vadim wrote: Show quoted text
> 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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 896b
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 I suppose that the same applies to gmake-based builds.
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Date: Wed, 28 Mar 2018 05:52:21 +0000
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.2k
Show quoted text
> 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 :)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 251b
On Tue, 27 Mar 2018 22:53:19 -0700, Vadim.Konovalov@dell.com wrote: Show quoted text
> 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?
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
Date: Wed, 28 Mar 2018 12:45:17 +0000
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 613b
Show quoted text
> 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; :):)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Wed, 28 Mar 2018 05:46:10 -0700, Vadim.Konovalov@dell.com wrote: Show quoted text
> 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
Date: Wed, 28 Mar 2018 14:30:46 +0000
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Download (untitled) / with headers
text/plain 692b
Show quoted text
> 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
... Show quoted text
> 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;
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 145b
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.
Subject: 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
Subject: 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
Subject: 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
Subject: 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
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Date: Thu, 29 Mar 2018 05:33:42 +0000
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 223b
Show quoted text
> 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 :)
Date: Thu, 29 Mar 2018 08:56:15 -0600
To: perlbug-followup [...] perl.org
Subject: Re: [perl #132992] [PATCH] for perl static build for gcc+win32
CC: perl5-porters [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 442b
On 03/28/2018 03:00 PM, Sergey Aleynikov via RT wrote: Show quoted text
> 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.perl.org/Ticket/Display.html?id=132992 >
Thanks, applied as 9999704e7aca19e4a03c68b26e66cbb421898bc3..122ce0a11ac3be141e90e47a2bb1a6a8a91a78bd Can this ticket be closed?
Date: Thu, 29 Mar 2018 15:05:58 +0000
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Show quoted text
> Can this ticket be closed?
Yes, I think so
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 648b
On Thu, 29 Mar 2018 07:56:39 -0700, public@khwilliamson.com wrote: Show quoted text
> 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.perl.org/Ticket/Display.html?id=132992 > >
> > > Thanks, applied as > 9999704e7aca19e4a03c68b26e66cbb421898bc3..122ce0a11ac3be141e90e47a2bb1a6a8a91a78bd > > 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
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
To: "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Date: Thu, 29 Mar 2018 15:51:46 +0000
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 470b
Show quoted text
> > 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.
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
From: Karl Williamson <public [...] khwilliamson.com>
Date: Thu, 29 Mar 2018 10:46:25 -0600
To: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>, "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Subject: Re: [perl #132992] [PATCH] for perl static build for gcc+win32
Download (untitled) / with headers
text/plain 749b
On 03/29/2018 09:51 AM, Konovalov, Vadim wrote: Show quoted text
>>> 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.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
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
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
To: Karl Williamson <public [...] khwilliamson.com>, "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
Date: Thu, 29 Mar 2018 19:45:44 +0000
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 714b
Show quoted text
> 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
Subject: RE: [perl #132992] [PATCH] for perl static build for gcc+win32
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
To: Karl Williamson <public [...] khwilliamson.com>, "perlbug-followup [...] perl.org" <perlbug-followup [...] perl.org>
From: "Konovalov, Vadim" <Vadim.Konovalov [...] dell.com>
Date: Fri, 30 Mar 2018 14:50:13 +0000
Download (untitled) / with headers
text/plain 869b
Show quoted text
> > 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; Show quoted text
> > 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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 241b
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
Download (untitled) / with headers
text/plain 317b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org