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

5.38.0.2 fails to build XS-libpanda-1.5.10 with gcc 13 #137

Closed
mimmo-m opened this issue Sep 18, 2023 · 18 comments
Closed

5.38.0.2 fails to build XS-libpanda-1.5.10 with gcc 13 #137

mimmo-m opened this issue Sep 18, 2023 · 18 comments

Comments

@mimmo-m
Copy link

mimmo-m commented Sep 18, 2023

Works with strawberry 5.32.1 on windows
Works with gcc 12.3.0 under linux but not with gcc 13.2.0

@shawnlaffan
Copy link
Contributor

shawnlaffan commented Sep 18, 2023

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.
(Edit: Alien::cmake3 uses hard coded paths, reinstalling it avoids the path issue).

@mimmo-m
Copy link
Author

mimmo-m commented Sep 19, 2023

Hello,
the issue is with Strawberry (I tested with your test release 5.38.02) and gcc 13 (you include in your distribution).
To exclude issues introduced by me I also checked on linux with gcc 13.2.0 (redhat and slackware) and XS::libpanda failed to build/.
On linux gcc 12.3.0 works fine.
From my limited knowledge I guess the problem is due to some syntax change introduced by gcc.

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).
Is there any suggestions you can give to reproduce the full build from scratch (excluding gcc)?
I got stuck when building libraries.

Many thanks,
Regards

@shawnlaffan
Copy link
Contributor

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)

@sisyphus
Copy link

sisyphus commented Sep 19, 2023

From my limited knowledge I guess the problem is due to some syntax change introduced by gcc.

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.
When I try to build it using SP-5.38.0, I get the following error:

cd clib/build && cd ../cmake_props && gmake  panda-lib
gmake[1]: Entering directory 'C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/cmake_props'
[ 10%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/error.cc.obj
[ 20%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/exception.cc.obj
[ 30%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/from_chars.cc.obj
[ 40%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/hash.cc.obj
[ 50%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/log/log.cc.obj
[ 60%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/memory.cc.obj
[ 70%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/refcnt.cc.obj
[ 80%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/win/exception.cc.obj
[ 90%] Building CXX object C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/build/CMakeFiles/panda-lib.dir/src/panda/win/exception_debug.cc.obj
In file included from C:/sp/_64/sp-5.38.0/c/x86_64-w64-mingw32/include/windows.h:9,
                 from C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/src/panda/win/exception_debug.cc:3:
C:/Users/Owner/.cpan/build/XS-libpanda-1.5.10-0/clib/src/panda/win/exception_debug.cc:7:5: error: redefinition of 'const GUID& __mingw_uuidof() [with T = IDebugClient; GUID = GUID]'
    7 |     __CRT_UUID_DECL(IDebugClient,0x27fe5639,0x8407,0x4f47,0x83,0x64,0xee,0x11,0x8f,0xb0,0x8a,0xc8)
      |     ^~~~~~~~~~~~~~~
C:/sp/_64/sp-5.38.0/c/x86_64-w64-mingw32/include/dbgeng.h:262:1: note: 'const GUID& __mingw_uuidof() [with T = IDebugClient; GUID = GUID]' previously declared here
  262 | __CRT_UUID_DECL(IDebugClient,0x27fe5639,0x8407,0x4f47,0x83,0x64,0xee,0x11,0x8f,0xb0,0x8a,0xc8)
      | ^~~~~~~~~~~~~~~

I notice that gcc-8.3.0's dbgeng.h does not define __CRT_UUID_DECL.
However, gcc-13's dbgeng.h does define __CRT_UUID_DECL and I think that's the problem.

There's some patching of the perl-5.38.0 source needed in order to build it with gcc-12 or gcc-13.
@shawnlaffan, is the patched 5.38.0 source that Strawberry Perl used downloadable from somewhere ??

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 __CRT_UUID_DECL, and I assume the same holds for gcc-12.3.x.)

Cheers,
Rob

@shawnlaffan
Copy link
Contributor

Thanks @sisyphus

SP 5.38 did not use any specific patches but the changed defines can be seen at

patch => { #DST paths are relative to the perl src root
'<dist_sharedir>/msi/files/perlexe.ico' => 'win32/perlexe.ico',
'<dist_sharedir>/perl-5.36/perlexe.rc.tt' => 'win32/perlexe.rc',
'config_H.gc' => {
I_DBM => 'define',
I_GDBM => 'define',
I_NDBM => 'define',
HAS_BUILTIN_CHOOSE_EXPR => 'define',
HAS_SYMLINK => 'define',
},
'config.gc' => { # see Step.pm for list of default updates
d_builtin_choose_expr => 'define',
d_mkstemp => 'define',
d_ndbm => 'define',
d_symlink => 'define', # many cpan modules fail tests when defined
i_db => 'define',
i_dbm => 'define',
i_gdbm => 'define',
i_ndbm => 'define',
osvers => '10',
},

These are applied using code within the build system but can be done by hand pretty easily when not using an automated system.

@sisyphus
Copy link

SP 5.38 did not use any specific patches ...

Duh ... yeah, just my fried brain ...IIRC, it was 5.36.1 that was the recent stable release needing patching.
Sorry.

Cheers,
Rob

@sisyphus
Copy link

@mimmo-m, it turns out that the dreaded __CRT_UUID_DECL has been backported to gcc-12.3.0, and the XS::libpanda build therefore fails in the same way. (I actually tested that.)
So, I tried the 12.2.0 compiler next.

gcc version 12.2.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders)

In the perl-5.38.0 source, I cd to the win32 folder and run:

gmake USE_QUADMATH=define I_QUADMATH=define CCHOME=C:\winlibs-gcc-1220\mingw64 CCTYPE=GCC USE_MINGW_ANSI_STDIO=define SKIP_CCHOME_CHECK=1 BUILDOPTEXTRA=-fdiagnostics-color=never INST_TOP=C:\perl-5.38.0-1220-q -j8 test

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 double when one can just as easily have a perl with an nvtype of __float128.)
The BUILDOPTEXTRA argument is also optional.
You'll need to modify the CCHOME argument to point to your gcc installation. (Note that it specifies the folder that contains the "bin" folder.)
Set INST_TOP to the location you want perl to go into.
All tests pass for me.

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:

set PATH=C:\perl-5.38.0-1220-q\bin;%PATH%

Then run cpan -i XS::libpanda
XS::libpanda failed a couple of tests:

Test Summary Report
-------------------
t/log/log.t          (Wstat: 1280 (exited 5) Tests: 0 Failed: 0)
  Non-zero exit status: 5
  Parse errors: No plan found in TAP output
t/log/module.t       (Wstat: 1280 (exited 5) Tests: 1 Failed: 0)
  Non-zero exit status: 5
  Parse errors: No plan found in TAP output
Files=24, Tests=142, 11 wallclock secs ( 0.11 usr +  0.02 sys =  0.13 CPU)
Result: FAIL
Failed 2/24 test programs. 0/142 subtests failed.
make.EXE: *** [Makefile:961: test_dynamic] Error 255
  SYBER/XS-libpanda-1.5.10.tar.gz
  C:\make\bin\make.EXE test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
  reports SYBER/XS-libpanda-1.5.10.tar.gz

Maybe it's just a missing logging capability - though a preliminary investigation indicates that something is segfaulting.
Rather than investigate any further, I just force installed XS::libpanda by running cpan -fi XS::libpanda

Let me know if you give that a try and it doesn't work for you.

Cheers,
Rob

@mimmo-m
Copy link
Author

mimmo-m commented Sep 19, 2023

@sisyphus I am building perl with gcc 12.3.0 (mingw-w64)
gmake INST_TOP=c:\mperl5380 CCHOME=c:\mingw-w64
not finished, I'll report my findings.
With gcc 12.3.0 on linux I have in production perl 5.38.0 with XS::libpanda 1.5.10 and have no problems.
May it be an issue introduced by mingw port of gcc?

Cherrs,
Mimmo

@sisyphus
Copy link

May it be an issue introduced by mingw port of gcc?

Yes, I think so. (Well spotted - I should have realized this earlier.)
"CRT" sounds windows-specific, and the dbgeng.h file begins with the following statement:

/**
 * This file has no copyright assigned and is placed in the Public Domain.
 * This file is part of the mingw-w64 runtime package.
 * No warranty is given; refer to the file DISCLAIMER.PD within this package.
 */

It seems that __CRT_UUID_DECL becomes a problem in mingwrt version 11.
My gcc-12.2.0 has version 10, but my gcc-12.3.0 has version 11 - which would explain that my 12.2 builds XS::libpanda, but my gcc-12.3 does not.

It's actually defined in _mingw.h:

#if defined(__cplusplus) && (USE___UUIDOF == 0)

#if __cpp_constexpr >= 200704l && __cpp_inline_variables >= 201606L
#define __CRT_UUID_DECL(type,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8)    \
    extern "C++" {                                               \
    template<> struct __mingw_uuidof_s<type> {                   \
        static constexpr IID __uuid_inst = {                     \
            l,w1,w2, {b1,b2,b3,b4,b5,b6,b7,b8}                   \
        };                                                       \
    };                                                           \
    template<> constexpr const GUID &__mingw_uuidof<type>() {    \
        return __mingw_uuidof_s<type>::__uuid_inst;              \
    }                                                            \
    template<> constexpr const GUID &__mingw_uuidof<type*>() {   \
        return  __mingw_uuidof_s<type>::__uuid_inst;             \
    }                                                            \
    }
#else
#define __CRT_UUID_DECL(type,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8)           \
    extern "C++" {                                                      \
    template<> inline const GUID &__mingw_uuidof<type>() {              \
        static const IID __uuid_inst = {l,w1,w2, {b1,b2,b3,b4,b5,b6,b7,b8}}; \
        return __uuid_inst;                                             \
    }                                                                   \
    template<> inline const GUID &__mingw_uuidof<type*>() {             \
        return __mingw_uuidof<type>();                                  \
    }                                                                   \
    }
#endif
....

And it's defined there for mingwrt-10, too.
But it apparently doesn't pose a problem with XS::libpanda until it's referenced by dbgeng.h - and that doesn't happen until we get to mingwrt-11.

You might need to raise this with the mingw-w64 people.
There's the [email protected] mailing list.
Bug tracker is at https://sourceforge.net/p/mingw-w64/bugs.

CCHOME=c:\mingw-w64

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 CCHOME=c:\mingw-w64\mingw64 or CCHOME=c:\mingw64.

Cheers,
Rob

@sisyphus
Copy link

You might need to raise this with the mingw-w64 people.

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:

--- ../XS-libpanda-1.5.10-9/clib/src/panda/win/exception_debug.cc       2022-04-12 00:33:54.000000000 +1000
+++ clib/src/panda/win/exception_debug.cc       2023-09-20 11:41:58.173708500 +1000
@@ -2,7 +2,7 @@
 #include "exception_debug.h"
 #include <windows.h>
 #include <dbgeng.h>
-
+/*
 #ifdef __CRT_UUID_DECL // for __MINGW32__
     __CRT_UUID_DECL(IDebugClient,0x27fe5639,0x8407,0x4f47,0x83,0x64,0xee,0x11,0x8f,0xb0,0x8a,0xc8)
     __CRT_UUID_DECL(IDebugControl,0x5182e668,0x105e,0x416e,0xad,0x92,0x24,0xef,0x80,0x04,0x24,0xba)
@@ -12,7 +12,7 @@
     DEFINE_GUID(IID_IDebugControl,0x5182e668,0x105e,0x416e,0xad,0x92,0x24,0xef,0x80,0x04,0x24,0xba);
     DEFINE_GUID(IID_IDebugSymbols,0x8c31e98c,0x983a,0x48a5,0x90,0x16,0x6f,0xe5,0xd6,0x67,0xa9,0x50);
 #endif
-
+*/
 using namespace panda;

 com_global_initer::com_global_initer() noexcept : _ok{false} {

When I get the time to run the checks I'll update this post with a portable patch to panda/win/exception_debug.cc.
(Or maybe someone else will do that for me ;-)

Note: t/log/log.t and t/log/module.t still fail for me.

Cheers,
Rob

@sisyphus
Copy link

As regards a portable patch that enables the building of XS-libpanda-1.5.10, this seems fine:

--- clib/src/panda/win/exception_debug.cc_orig  2022-04-12 00:33:54.000000000 +1000
+++ clib/src/panda/win/exception_debug.cc       2023-09-20 21:42:54.264834500 +1000
@@ -3,6 +3,7 @@
 #include <windows.h>
 #include <dbgeng.h>

+#if __MINGW64_VERSION_MAJOR < 11
 #ifdef __CRT_UUID_DECL // for __MINGW32__
     __CRT_UUID_DECL(IDebugClient,0x27fe5639,0x8407,0x4f47,0x83,0x64,0xee,0x11,0x8f,0xb0,0x8a,0xc8)
     __CRT_UUID_DECL(IDebugControl,0x5182e668,0x105e,0x416e,0xad,0x92,0x24,0xef,0x80,0x04,0x24,0xba)
@@ -12,6 +13,7 @@
     DEFINE_GUID(IID_IDebugControl,0x5182e668,0x105e,0x416e,0xad,0x92,0x24,0xef,0x80,0x04,0x24,0xba);
     DEFINE_GUID(IID_IDebugSymbols,0x8c31e98c,0x983a,0x48a5,0x90,0x16,0x6f,0xe5,0xd6,0x67,0xa9,0x50);
 #endif
+#endif

 using namespace panda;

Tested against against the following 64-bit builds:
perl-5.39.2, built by gcc-13.2.0 (mingwrt 11)
perl-5.38.0, built by gcc-13.1.0 (mingwrt 11)
perl-5.38.0, built by gcc-12.3.0 (mingwrt 11)
perl-5.38.0, built by gcc-12.2.0 (mingwrt 10)
perl-5.36.0, built by gcc-11.3.0 (mingwrt 10)
perl-5.32.1, built by gcc-8.3.0 (mingwrt 6 )

And also tested against the following 32-bit (64-bit integer) builds:
perl-5.38.0, built by gcc-13.1.0 (mingwrt 11)
perl-5.36.0, built by gcc-11.3.0 (mingwrt 10)
perl-5.32.1, built by gcc-8.3.0 (mingwrt 6)

Except for the 5.32.1 builds, I find that t/log/log.t and t/log/module.t fail.
I noticed also that my 32-bit build of perl-5.36.1 failed t/log/logger.t. (Perhaps there are other perls that failed that same test script and I didn't notice at the time.)

With those builds of XS-libpanda-1.5.10 that failed those logging tests, I saw the following

....
[ 75%] Building CXX object D:/s/XS-libpanda-1.5.10/clib/build/CMakeFiles/panda-lib-tests.dir/tests/string_char.cc.obj
D:/s/XS-libpanda-1.5.10/clib/tests/string_char.cc: In function 'void test_compilation_warnings()':
D:/s/XS-libpanda-1.5.10/clib/tests/string_char.cc:10:76: warning: 'abc' may be used uninitialized [-Wmaybe-uninitialized]
   10 |         auto data = string("\x05\x01\x00\x01") + string((char*)&abc, 16) + string((char*)&abc, 2);
      |                                                                            ^~~~~~~~~~~~~~~~~~~~~~
In file included from D:/s/XS-libpanda-1.5.10/clib/src/panda/string.h:2,
                 from D:/s/XS-libpanda-1.5.10/clib/tests/test.h:3,
                 from D:/s/XS-libpanda-1.5.10/clib/tests/string_test.h:2,
                 from D:/s/XS-libpanda-1.5.10/clib/tests/string_char.cc:1:
D:/s/XS-libpanda-1.5.10/clib/src/panda/basic_string.h:209:5: note: by argument 2 of type 'const char*' to 'panda::basic_string<CharT, Traits, Alloc>::basic_string(const CharT*, panda::basic_string<CharT, Traits, Alloc>::size_type) [with CharT = char; Traits = std::char_traits<char>; Alloc = panda::DefaultStaticAllocator<char>]' declared here
  209 |     basic_string (const CharT* str, size_type len) : _length(len) {
      |     ^~~~~~~~~~~~
D:/s/XS-libpanda-1.5.10/clib/tests/string_char.cc:9:11: note: 'abc' declared here
    9 |         } abc;
      |           ^~~
[ 77%] Building CXX object D:/s/XS-libpanda-1.5.10/clib/build/CMakeFiles/panda-lib-tests.dir/tests/string_char16.cc.obj
....

With 5.32.1 (which passed all tests) there were no warnings issued.
Perhaps those warnings are related to those test failures.

Cheers,
Rob

@mimmo-m
Copy link
Author

mimmo-m commented Sep 20, 2023

@sisyphus I will test your patch
To summarize I have:
winlibs gcc12.3.0 -->error
linux gcc1230 --> OK
winlibs gcc1320 --> error
linux gcc1320 --> error
Mimmo

@mimmo-m
Copy link
Author

mimmo-m commented Sep 23, 2023

@sisyphus Hello, your patch works also for me.
gcc 13 (win32 and linux) does not compile the Date module, I will open a bug to the developer.
I have hacked the 5.38.0.2 using winlibs_gcc12.2.0, it works for those who need win32+perl5.38+Date.
Cheers,
Mimmo

@sisyphus
Copy link

The first problem I see with Date-5.2.12 is that the prerequisite XS-Framework-1.5.5 fails a couple of tests.
I get around that by running cpan -fi XS::Framework.

However, Date-5.2.12 then fails to compile:

gmake[1]: Entering directory 'D:/s/Date-5.2.12/clib/cmake_props'
[  9%] Building CXX object D:/s/Date-5.2.12/clib/build/CMakeFiles/panda-date.dir/src/panda/date/Date.cc.obj
In file included from D:/s/Date-5.2.12/clib/src/panda/date/Date.h:2,
                 from D:/s/Date-5.2.12/clib/src/panda/date/Date.cc:1:
D:/s/Date-5.2.12/clib/src/panda/date/error.h:6:6: warning: elaborated-type-specifier for a scoped enum must not use the 'class' keyword
    6 | enum class errc : uint8_t {
      | ~~~~ ^~~~~
      |      -----
D:/s/Date-5.2.12/clib/src/panda/date/error.h:6:17: error: found ':' in nested-name-specifier, expected '::'
    6 | enum class errc : uint8_t {
      |                 ^
      |                 ::
 .... [more errors follow]

When C++ code gets involved, I quickly lose interest ;-)

Cheers,
Rob

@mimmo-m
Copy link
Author

mimmo-m commented Sep 23, 2023

In this case I found a simple
#include <cstdint>
in clib/src/panda/date/error.h
solves all problems.

Cheers,
Mimmo

@shawnlaffan
Copy link
Contributor

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.
shawnlaffan/perl-alien-geos@870bd9a

@sisyphus
Copy link

#include <cstdint>

Yep - that works fine for me, too.

Cheers,
Rob

@shawnlaffan
Copy link
Contributor

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.

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

No branches or pull requests

3 participants