Open hakonhagland opened 1 year ago
Aaah ... I don't think perl is buildable with UCRT. For me, there are no problems with current blead (commit 2edec0e0c82cf00befaffdbced3b22aef1eef8d7) built using Brecht Sanders' gcc-12.2.0 with MSVCRT on Windows 11.
There's some recent (ie May 2021) discussion about the possibility of using UCRT at https://github.com/Perl/perl5/issues/18772. In the light of that discussion, UCRT support does not seem imminent, IMO.
BTW, have you noticed how slow 12.2.0 is at compiling perl's C source files ? It's much slower than 12.1.0 which, in turn, was noticeably slower than mingw-w64 ports of earlier gcc versions. Do you have any thoughts on why that is ?
Cheers, Rob
I guess this will compile if you undefine USE_STDIO_PTR
win32/config_H.gc
I guess this will compile if you undefine USE_STDIO_PTR
@Leont I tried this change:
diff --git a/win32/config_H.gc b/win32/config_H.gc
index 2533efd059..750e62d5b6 100644
--- a/win32/config_H.gc
+++ b/win32/config_H.gc
@@ -1084,7 +1084,7 @@
* This symbol is defined if using the FILE_ptr macro as an lvalue
* to increase the pointer by n leaves File_cnt(fp) unchanged.
*/
-#define USE_STDIO_PTR /**/
+/*#define USE_STDIO_PTR */
#ifdef USE_STDIO_PTR
#define FILE_ptr(fp) ((fp)->_ptr)
#define STDIO_PTR_LVALUE /**/
and recompiled
c:\PerlWinLib\perl5\win32>mingw32-make.exe
[...]
gcc -c -I.\include -I. -I.. -DWIN32 -DWIN64 -DPERLDLL -DPERL_CORE -Os -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\perlio.o ..\perlio.c
In file included from ..\perl.h:3723,
from ..\perlio.c:43:
..\perlio.c: In function 'PerlIOStdio_invalidate_fileno':
./win32.h:343:33: error: 'FILE' {aka 'struct _iobuf'} has no member named '_file'
343 | #define PERLIO_FILE_file(f) ((f)->_file)
| ^~
./win32.h:343:33: note: in definition of macro 'PERLIO_FILE_file'
343 | #define PERLIO_FILE_file(f) ((f)->_file)
| ^~
..\perlio.c: In function 'PerlIOStdio_get_base':
./win32.h:340:33: error: 'FILE' {aka 'struct _iobuf'} has no member named '_base'
340 | #define PERLIO_FILE_base(f) ((f)->_base)
| ^~
[...]
I think I get exactly the same error as before.
Aaah ... I don't think perl is buildable with UCRT.
@sisyphus Yes! I missed the distinction between the runtimes and downloaded the UCRT version.
I tried now with the MSVCRT version of the compiler tools, and am able to build more, but it still fails due to gmake
not found:
> mingw32-make.exe
[...]
C:\PerlWinLib\perl5\warnings.h -> C:\PerlWinLib\perl5\lib\CORE\warnings.h
C:\PerlWinLib\perl5\XSUB.h -> C:\PerlWinLib\perl5\lib\CORE\XSUB.h
C:\PerlWinLib\perl5\zaphod32_hash.h -> C:\PerlWinLib\perl5\lib\CORE\zaphod32_hash.h
81 File(s) copied
rem. > .coreheaders
..\miniperl.exe -I..\lib ..\make_ext.pl "MAKE=gmake" --dir=..\ext --dir=..\dist --dynaloader
Generating a gmake-style Makefile
Writing Makefile for DynaLoader
'gmake' is not recognized as an internal or external command,
operable program or batch file.
'gmake' is not recognized as an internal or external command,
operable program or batch file.
Unsuccessful make(ext/DynaLoader): code=256 at ..\make_ext.pl line 584.
mingw32-make: *** [GNUmakefile:1578: ..\DynaLoader.o] Error 2
I tried to make an alias to gnu make like this:
> doskey gmake=mingw32-make.exe $*
> gmake
# CCTYPE=GCC
# GCCBIN=gcc
# GCCVER=12.2.0
# GCCTARGET=x86_64-w64-mingw32
# GCCCROSS=
# WIN64=define
# ARCHITECTURE=x64
# ARCHNAME=MSWin32-x64-multi-thread
# MAKE=gmake
..\miniperl.exe -I..\lib ..\make_ext.pl "MAKE=gmake" --dir=..\ext --dir=..\dist --dynaloader
'gmake' is not recognized as an internal or external command,
operable program or batch file.
'gmake' is not recognized as an internal or external command,
operable program or batch file.
Unsuccessful make(ext/DynaLoader): code=256 at ..\make_ext.pl line 584.
mingw32-make: *** [GNUmakefile:1578: ..\DynaLoader.o] Error 2
but it still fails..
but it still fails due to gmake not found
I actually build my Windows perls using a gnu make utility named 'make.exe', and I don't use the command 'gmake' at all.
When I build perl I run 'make
That all works fine - though perl -V:make
reports 'gmake', and various messages generated by EU::MM report mention 'gmake'.
However, sitting next to 'make.exe', I've created a copy of that file named 'gmake.exe'. So maybe that's part of how my unorthodox arrangement works.
I think it would work ok if you created a copy of mingw32-make.exe with a name of 'gmake.exe' and placed that copy in your PATH. After all, mingw32-make.exe is just 'GNU make' under a different name:
D:\>mingw32-make -v
GNU Make 4.3
Built for x86_64-w64-mingw32
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
I don't know much about the aliasing procedure you tried, and why it didn't work.
Cheers, Rob
I think it would work ok if you created a copy of mingw32-make.exe with a name of 'gmake.exe' and placed that copy in your PATH.
@sisyphus Yes, that worked. I made a copy of mingw32-make.exe
and called it gmake.exe
(and placed it in the same folder). Now, rerunning gmake
gives no errors.
However, when I subsequently run gmake test
I have some test failures. I will report those in a new issue later.
I have some test failures. I will report those in a new issue later.
Added a new issue: https://github.com/Perl/perl5/issues/20391
I think it would work ok if you created a copy of mingw32-make.exe with a name of 'gmake.exe' and placed that copy in your PATH.
@sisyphus Yes, that worked. I made a copy of
mingw32-make.exe
and called itgmake.exe
(and placed it in the same folder). Now, rerunninggmake
gives no errors.However, when I subsequently run
gmake test
I have some test failures. I will report those in a new issue later.
@hakonhagland, @sisyphus, Are there any issues still needing attention in this ticket?
Are there any issues still needing attention in this ticket?
I don't think so.
There might be an issue regarding the failure of doskey gmake=mingw32-make.exe $*
to create the alias that @hakonhagland expected.
I don't know about that, but I doubt it has anything at all to do with perl.
Cheers, Rob
I think it would work ok if you created a copy of mingw32-make.exe with a name of 'gmake.exe' and placed that copy in your PATH.
@sisyphus Yes, that worked. I made a copy of
mingw32-make.exe
and called itgmake.exe
(and placed it in the same folder). Now, rerunninggmake
gives no errors. However, when I subsequently rungmake test
I have some test failures. I will report those in a new issue later.@hakonhagland, @sisyphus, Are there any issues still needing attention in this ticket?
No ongoing issues cited. Closing ticket.
I should have responded earlier to this. I believe that perl should work out of the box on whatever box it is installed on, without having to configure git.
The reason buildtoc is failing is that it reads the pod in :raw
mode and enables paragraph slurping. by setting $/ = ""
. Paragraph mode does not understand CR-LF, so it slurps the whole file.
I have a patch, but am unsure if it's the correct thing to do. Instead of using :raw
, it uses plain :
A colon with no name following it uses the default layer for the operating system (:raw
on Unix, :crlf
on Windows).
But maybe a better fix is to change paragraph slurping
@khwilliamson, I think you probably meant to re-open #20391, not this issue. As @jkeenan notes in #20391, the point you're making enters the realm of "perl policy" and might therefore better be discussed on p5p. (I don't know.) Cheers, Rob
I am trying to build blead on Windows 11 using MinGW-w64 and gcc from https://winlibs.com/ following a similar approach as in https://github.com/Perl/perl5/issues/20096. This is gcc version 12.2.0, and gnu make version 4.3:
Running gnu make in the
win32
folder gives output: