-
Notifications
You must be signed in to change notification settings - Fork 581
5.41.13 thru EU::MM 7.72 breaks all i386 Win32 XS .dll during linking if they add any extra "-lsome_c_lib"es #23331
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
Comments
Perl-Toolchain-Gang/ExtUtils-MakeMaker@2c61b35 is the relevant change in EUMM. |
This is a revert needed in core issue at this point. Its not a wait for EUMM TC group, to go through the original minor flaw/minor defect and go through the broken "improvement" commit and work out a fix for the broken improvement, that probably involves discussing and modifying high river Public PP CPAN APIs. Is support for i386/32 bit CPUs going to be officially dropped in 5.42.0 stable? |
I've just built 32-bit Windows build of current blead (at commit 79d4169), using gcc-15.1.0 (from https://winlibs.com) and can't find any issue.
Note that I build my perl with the
How do I get to experience the problem that you are seeing ? |
IDK how Winlibs.com configs/bundles their GCC, and is it of mingw.org or mingw64 family, winlibs.com claims to be a mingw64, which I consider the good fork. I use whatever GCC binaries/headers that came with various different Strawberry Perls I installed. All Strawberrys come with GCCs compiled from source by Strawberry project ppl. Except early on when they distributed a GCC binary from H**L called mingw.org 3.4.5 For the above errors, I am using
expand``` libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic -- enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-st ring --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-sjlj-exceptions --with-dwarf2 --disable-libstdcxx-pch --disable-libst dcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disabl e-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch =i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/opt/bui ld/prerequisites/i686-w64-mingw32-static --with-mpfr=/opt/build/prerequisites/i6 86-w64-mingw32-static --with-mpc=/opt/build/prerequisites/i686-w64-mingw32-stati c --with-isl=/opt/build/prerequisites/i686-w64-mingw32-static --with-pkgversion= 'i686-posix-dwarf, Built by strawberryperl.com project' --with-bugurl=https://so urceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/opt/build/i686- 830-posix-dwarf-rt_v6/mingw32/opt/include -I/opt/build/prerequisites/i686-zlib-s tatic/include -I/opt/build/prerequisites/i686-w64-mingw32-static/include' CXXFLA GS='-O2 -pipe -fno-ident -I/opt/build/i686-830-posix-dwarf-rt_v6/mingw32/opt/inc lude -I/opt/build/prerequisites/i686-zlib-static/include -I/opt/build/prerequisi tes/i686-w64-mingw32-static/include' CPPFLAGS=' -I/opt/build/i686-830-posix-dwar f-rt_v6/mingw32/opt/include -I/opt/build/prerequisites/i686-zlib-static/include -I/opt/build/prerequisites/i686-w64-mingw32-static/include' LDFLAGS='-pipe -fno- ```
Use the i386 GCC that came with i386 Straw 5.32.
CUT
Do you see the |
I 've never CC_HOME env var in the root makefile, my GCCs can find their /lib folder automatically. changing Win32.pms makefile by hand, top is from current blead to bottom version fixes the link failure
|
Perl-Toolchain-Gang/ExtUtils-MakeMaker#277 might be related but bug ticket was opened in 2018 |
Building blead (at commit 79d4169) using that compiler, I start with:
That all proceeds without error for me - so I run the test suite:
I get:
I'm still not seeing any issue. Here is the
According to |
Type |
You want me to just accept all defaults ? Unsurprisingly the process croaked after a minute or so with:
So, I try to rebuild from scratch with:
But the build eventually fails with:
I just don't understand the point of all this. |
I've just noticed that current blead and perl-5.41.13 both have EU-MM-7.76, whereas the title of this issue refers to version 7.72. UPDATE: Aaah ... at last I see the similarity between what I got and what @bulk88 got - including the full paths to the Windows dlls (that I had snipped out). |
Edit: I forgot to include Yes @sisyphus you reproduced what I am seeing. Previously Mingw GCC built stable perls/older EU::MMs just complain in the console with approx A very recent new feature in EU::MM that mohawk added, but I can't find a PR or any discussion about it. I only see the commits related to the new feature in EU::MM, is to allow Linux style runtime static linking from importer XS_one.dll to exporter XS_two.dll. Both are CPAN XS modules. This feature is a wishlist item, its not a critical fix for EU::MM. EU::MM and WinGCCPerl/Strawberry have been happy without the new feature for the last 15-20 years. Now that EU::MM or one of its subclasses, wants to pretend that it is smarter than the Or maybe, I didn't single step Then EU::MM deletes all the The code inside MS un-mangles In reality, Mingw Project uses a different algorithm than the one inside See https://github.com/mirror/mingw-w64/blob/master/mingw-w64-tools/gendef/src/gendef.c Mingw Project uses a light weight i386 machine code decompiler to generate Mingw's/WinGCC's .a files and decide if the symbol is Totally unrealistic to use inside EU::MM/Perl core, but i386 The EU::MM new feature shouldn't ship in the next stable perl, since it needs rework and improvement. It only works on x64 WinGCCPerl since Win64 all CPUs permanently eliminated C89/C99 name mangling of C89/C99 function/data symbols for PE Import/Export Table purposes, as part of Win64 having 1 universal ABI per CPU arch. Not multiple ABIs and calling conventions like it did on Win32 on i386. |
My understanding of this stuff is quite weak. I switched from building bleadperl to building perl-5.41.9 (EU-MM-7.70), again by doing
On my machine, the Was there ever a time that you could successfully build perl without specifying CCHOME if "CCHOME" is not the default "C:\MinGW" ? |
Yes I was able to. I just tried a fresh git checkout of 5.30.0 i386 against i386 Strawberry 5.32's GCC. I have no build or test problems with Edit: You are now hitting code rot from Win32.pm added in 2022 with not fully-correct PRs (see perl-libwin32/win32#30 ) being merged and published, and example of buggyness that PR added in perl-libwin32/win32#38
See long list of unanswered PRs in https://github.com/perl-libwin32/win32/pulls Edit 2: Win32.pm has certified by P5P code rot see https://github.com/Perl/perl5/blob/blead/t/porting/customized.dat#L19
|
Module: EU::MM in blead
Description
This bug blocks Perl 5.42.0. I don't have time to rewrite all this ATM.
problem code inside
cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
console failure
Steps to Reproduce
Try building a i386 WinMingwGCCPerl with 5.41.13
Expected behavior
I have a new i386 WinGCCPerl on my disk.
Perl configuration
The text was updated successfully, but these errors were encountered: