-
Notifications
You must be signed in to change notification settings - Fork 49
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
5.38.0.2 fails to build XS-libpanda-1.5.10 with gcc 13 #137
Comments
It seems from your comment that this problem is not with Strawberry Perl, as it applies to gcc-13 across platforms? If so then the issue should be reported to the XS::libpanda issue tracker, although it seems this has already been done: https://rt.cpan.org/Public/Bug/Display.html?id=149073 FWIW, I get build failures with the XS::libcatch dependency due to incorrect paths being used (my portable perls have been moved and something is using the previous path). I have not yet tracked them down. |
Hello, Yes I submitted https://rt.cpan.org/Public/Bug/Display.html?id=149073 but, since I get the same issue on linux, it is not a problem of paths. I have tried to build strawberry with gcc 12.3 but I couldn't (also, but not only, because I have not enough time to dedicate). Many thanks, |
Thanks for the additional details. However, the fact that the issue is related to gcc-13 means it needs to be fixed by the maintainers of XS-libpanda. In terms of building with gcc-12, have a look at https://github.com/StrawberryPerl/spbuild to get started. If you don't ned the external libs then you can build a perl directly. See for example #39 (comment) |
Yes, I think that's right - which is what @shawnlaffan was getting at when he said it's not a Strawberry Perl issue. When I build XS::libpanda using SP-5.32.1 I find it all goes well for me, too.
I notice that gcc-8.3.0's dbgeng.h does not define There's some patching of the perl-5.38.0 source needed in order to build it with gcc-12 or gcc-13. Using a perl-5.38.0 built with gcc-12 will likely allow @mimmo-m to install XS::libpanda. (At least, my gcc-12.2.0's dbgeng.h does not define the troublesome Cheers, |
Thanks @sisyphus SP 5.38 did not use any specific patches but the changed defines can be seen at Perl-Dist-Strawberry/share/64bit-5.38.0.1.pp Lines 59 to 79 in 427b956
These are applied using code within the build system but can be done by hand pretty easily when not using an automated system. |
Duh ... yeah, just my fried brain ...IIRC, it was 5.36.1 that was the recent stable release needing patching. Cheers, |
@mimmo-m, it turns out that the dreaded
In the perl-5.38.0 source, I cd to the
If you don't want a quadmath build, you can remove the "USE_QUADMATH" and "I_QUADMATH" args. (I personally think it's dumb to accept a perl with an nvtype of Next I install perl by running the exact same command - except that I replace "test" (at the end of the command) with "install". Then insert this perl at the beginning of the PATH:
Then run
Maybe it's just a missing logging capability - though a preliminary investigation indicates that something is segfaulting. Let me know if you give that a try and it doesn't work for you. Cheers, |
@sisyphus I am building perl with gcc 12.3.0 (mingw-w64) Cherrs, |
Yes, I think so. (Well spotted - I should have realized this earlier.)
It seems that It's actually defined in _mingw.h:
And it's defined there for mingwrt-10, too. You might need to raise this with the mingw-w64 people.
That looks a bit odd, though it's not necessarily wrong. 64-bit winlibs distros normally unpack into a "mingw64" directory, so I would have expected either Cheers, |
Correction: It's actually up to the maintainers of panda to fix the source in a portable way. Here is a simple patch (hack) to XS-libpanda-1.5.10/clib/src/panda/win/exception_debug.cc that will allow XS::libpanda to build with mingwrt-11 - by simply commenting out the offending #ifdef/#else/#endif block of code:
When I get the time to run the checks I'll update this post with a portable patch to panda/win/exception_debug.cc. Note: t/log/log.t and t/log/module.t still fail for me. Cheers, |
As regards a portable patch that enables the building of XS-libpanda-1.5.10, this seems fine:
Tested against against the following 64-bit builds: And also tested against the following 32-bit (64-bit integer) builds: Except for the 5.32.1 builds, I find that t/log/log.t and t/log/module.t fail. With those builds of XS-libpanda-1.5.10 that failed those logging tests, I saw the following
With 5.32.1 (which passed all tests) there were no warnings issued. Cheers, |
@sisyphus I will test your patch |
@sisyphus Hello, your patch works also for me. |
The first problem I see with Date-5.2.12 is that the prerequisite XS-Framework-1.5.5 fails a couple of tests. However, Date-5.2.12 then fails to compile:
When Cheers, |
In this case I found a simple Cheers, |
There are likely many such cases in the wild. libgeos, for example, needed similar patching for gcc-13 when building it as an alien module. |
Yep - that works fine for me, too. Cheers, |
This issue seems to be resolved now so I'll close it. It can be re-opened if there are still things that need to be resolved. Otherwise new topics can be raised under new issues. |
Works with strawberry 5.32.1 on windows
Works with gcc 12.3.0 under linux but not with gcc 13.2.0
The text was updated successfully, but these errors were encountered: