perl 5.36 cpan | several Crypt:: builds are failing #80

shawnlaffan · 2023-03-16T03:02:42Z

Several of the Crypt builds are failing in a similar manner.

Crypt::OpenSSL::Bignum (perl 5.36 cpan | Crypt::OpenSSL::Bignum build fails #79)
Crypt::OpenSSL::DSA
Crypt::OpenSSL::RSA
Crypt::OpenSSL::Random
Crypt::OpenSSL::AES-0.05
Crypt::CBC

A common theme in the logs is Warning (mostly harmless): No library found for -leay32 (or -lssl32) followed later by errors like those below, but with differing source files:

c:/strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: AES.o:AES.c:(.text+0
x264): undefined reference to `AES_decrypt'
c:/strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: AES.o:AES.c:(.text+0
x2a1): undefined reference to `AES_encrypt'

Possibly there is an issue with the SSL libs. Or it is similar to #76 where libs are not correctly passed, and which suggests a broader issue with the 5.36 builds.

I can provide full logs for each if needed.

The text was updated successfully, but these errors were encountered:

sisyphus · 2023-03-16T06:06:42Z

I think those "(mostly harmless)" warnings are, indeed, harmless.
IIRC, the Makefile.PL links to a number of possible names that the relevant libraries might have - and MM simply removes the links that can't be resolved (and tells us about it).

AES_decrypt and AES_encrypt should be resolved by C:\strawberry\c\lib\libcrypto.a.
I suspect that the crucial -lcryptolink is not being provided during the build.
I'll take a look.

To build "Crypt::CBC" on sp536_20230311, I first needed to perform the same trick as was used for bareword::filehandles in order to install the pre-requisite "multidimensional".
That is:
set LIBRARY_PATH=C:\strawberry\perl\vendor\lib\auto\B\Hooks\OP\Check
then:
cpanm -i multidimensional --configure-args="LDDLFLAGS=\"-shared -s -LC:/strawberry/perl/lib/CORE -LC:/strawberry/c/lib -LC:/strawberry/c/x86_64-w64-mingw32/lib -LC:/strawberry\c/lib/gcc/x86_64-w64-mingw32/10.3.0 -lCheck.xs\""
then:
cpanm -i Crypt::CBC

I'll post "solutions" (for want of a better word) to the issues with the other Crypt::* modules mentioned in this ticket as II find them.

Edited to restore backslashes that had been removed.

Cheers,
Rob

sisyphus · 2023-03-16T06:25:12Z

Having built and installed Crypt::CBC on sp536_20230311, I find that Crypt::OpenSSL::RSA, Crypt::OpenSSL::Random, Crypt::OpenSSL::AES-0.05 and Crypt::OpenSSL::Bignum-0.09 are all installed (in vendor) and up to date.
Crypt::OpenSSL::DSA-0.20 also builds ok but fails 2 tests:

Test Summary Report
-------------------
t/10-selftest.t      (Wstat: 1280 (exited 5) Tests: 5 Failed: 0)
  Non-zero exit status: 5
  Parse errors: Bad plan.  You planned 36 tests but ran 5.
t/90-openssl-compat.t (Wstat: 1280 (exited 5) Tests: 0 Failed: 0)
  Non-zero exit status: 5
  Parse errors: Bad plan.  You planned 84 tests but ran 0.
Files=3, Tests=6,  7 wallclock secs ( 0.02 usr +  0.01 sys =  0.03 CPU)
Result: FAIL
Failed 2/3 test programs. 0/6 subtests failed.
gmake: *** [makefile:1042: test_dynamic] Error 5
FAIL

I'm not seeing any unresolved symbols at all.

Cheers,
Rob

shawnlaffan · 2023-03-16T06:44:19Z

Thanks once again Rob.

Ideally this should all work out of the box. The need for such a workaround makes me suspect that something is missing in the build, and it's likely to affect other modules users try to install.

That's all beyond my skill set so hopefully someone can provide suggestions.

shawnlaffan · 2023-03-16T06:53:46Z

cpanm -i multidimensional --configure-args="LDDLFLAGS="-shared -s -LC:/strawberry/perl/lib/CORE -LC:/strawberry/c/lib -LC:/strawberry/c/x86_64-w64-mingw32/lib -LC:/strawberry\c/lib/gcc/x86_64-w64-mingw32/10.3.0 -lCheck.xs""

I suspect GH formatting is mangling the escapes as I cannot get that to work. Can you format the invocation as a code block inside the three backticks?

sisyphus · 2023-03-16T08:49:07Z

Ideally this should all work out of the box.

Yes. Unfortunately I think that bareword::filehandles and multidimensional are not going to build out of the box until @ilmari addresses https://rt.cpan.org/Public/Bug/Display.html?id=147149 and then applies the same fix to multidimensional.

Mind you - I don't know how the bareword::filehandles/multidimensional install procedures are supposed to work.
If I find the time and inclination to build them on Ubuntu, I might be able to get a better idea.

I suspect GH formatting is mangling the escapes as I cannot get that to work.

Yes, you need to escape the 2nd and 3rd of 4 the double-quotes:
cpanm -i multidimensional --configure-args="LDDLFLAGS=\"-shared -s -LC:/strawberry/perl/lib/CORE -LC:/strawberry/c/lib -LC:/strawberry/c/x86_64-w64-mingw32/lib -LC:/strawberry\c/lib/gcc/x86_64-w64-mingw32/10.3.0 -lCheck.xs\""
It's exactly the same invocation as used for bareword::filehandles (except, of course, that the name of the module being installed has changed.

Cheers,
Rob

sisyphus · 2023-03-16T09:16:35Z

Mind you - I don't know how the bareword::filehandles/multidimensional install procedures are supposed to work.

Duh they're relying on ExtUtils::Depends - which is even more appalling than Win32::API (IMO).
In my experiences with EU::Depends wrt Gtk2, I came to conclude (without ever having proven it) that ExtUtils::Depends can't handle Strawberry's ".xs.dll" suffix.

However, I'm finding exactly the same problem on my own builds of perl-5.36.0 - where the ".xs.dll" issue is not present.
So maybe ExtUtils::Depends has some shortcoming with Windows.
Possibly it's just that, with Check.dll, the hook_op_check function is not exportable. (On linux, AIUI, every function in the shared object is available .)
The fix might be that Check.dll needs to be built such that hook_op_check is marked for export - if ExtUtils::Depends is to be able to access that function.

Dunno .... not sure that I have the ability to determine exactly what needs to be done. (Best thing, IMO, would be for these 2 troublesome modules to avoid the EU::Depends denpendency.)

Cheers,
Rob

shawnlaffan · 2023-03-16T09:33:34Z

I still cannot get that to work, but assume it's a PEBKAC.

One thing I do notice is that the 5.32 build for multidimensional has uses full path names for the libs to link.

Newlines added for readability.

Perl 5.36:

g++.exe multidimensional.def -o blib\arch\auto\multidimensional\multidimensional.xs.dll -shared -s 
-LC:/strawberry/perl/lib/CORE -LC:/strawberry/c/lib -LC:/strawberry/c/x86_64-w64-mingw32/lib 
-LC:/strawberry/c/lib/gcc/x86_64-w64-mingw32/10.3.0 -lCheck.xs multidimensional.o   
"C:\strawberry\perl\lib\CORE\libperl536.a" -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool 
-lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm 
-lversion -lodbc32 -lodbccp32 -lcomctl32 
-Wl,--enable-auto-image-base

Perl 5.32 (edited so base paths look the same):

g++.exe multidimensional.def -o blib\arch\auto\multidimensional\multidimensional.xs.dll -mdll -s -L"C:\strawberry\perl\lib\CORE" 
-L"C:\strawberry\c\lib" multidimensional.o   "C:\strawberry\perl\lib\CORE\libperl532.a" 
"C:\strawberry\perl\vendor\lib\auto\B\Hooks\OP\Check\Check.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libmoldname.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libkernel32.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libuser32.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libgdi32.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libwinspool.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libcomdlg32.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libadvapi32.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libshell32.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libole32.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\liboleaut32.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libnetapi32.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libuuid.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libws2_32.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libmpr.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libwinmm.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libversion.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libodbc32.a" 
"C:\strawberry\c\x86_64-w64-mingw32\lib\libodbccp32.a" "C:\strawberry\c\x86_64-w64-mingw32\lib\libcomctl32.a" 
-Wl,--enable-auto-image-base

And if one compares the perl -V output then there are some differences. For example:

uname I have broken in a previous commit so need to fix.
lddflags has ``-mdll``` in 5.32 but not 5.36.
5.32 defines PERL_IMPLICIT_CONTEXT while 5.36 does not.

--- 532.txt     2023-03-16 20:17:25.736107700 +1100
+++ 536.txt     2023-03-16 20:13:28.937796000 +1100
@@ -1 +1 @@
-Summary of my perl5 (revision 5 version 32 subversion 1) configuration:
+Summary of my perl5 (revision 5 version 36 subversion 0) configuration:
@@ -5 +5 @@
-    osvers=10.0.19042.746
+    osvers=10.0.17763.3406
@@ -7 +7 @@
-    uname='Win32 strawberry-perl 5.32.1.1 #1 Sun Jan 24 15:00:15 2021 x64'
+    uname=''
@@ -19 +18,0 @@
-    bincompat5005=undef
@@ -22,2 +21,2 @@
-    ccflags =' -DWIN32 -DWIN64 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields'
-    optimize='-s -O2'
+    ccflags =' -DWIN32 -DWIN64 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -mms-bitfields'
+    optimize='-O2'
@@ -26 +25 @@
-    gccversion='8.3.0'
+    gccversion='10.3.0'
@@ -48,3 +47,3 @@
-    ld='g++.exe'
-    ldflags ='-s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"'
-    libpth=C:\strawberry\c\lib C:\strawberry\c\x86_64-w64-mingw32\lib C:\strawberry\c\lib\gcc\x86_64-w64-mingw32\8.3.0
+    ld='g++'
+    ldflags ='-s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib" -L"C:\strawberry\c\x86_64-w64-mingw32\lib" -L"C:\strawberry\c\lib\gcc\x86_64-w64-mingw32\10.3.0"'
+    libpth=C:\strawberry\c\lib C:\strawberry\c\x86_64-w64-mingw32\lib C:\strawberry\c\lib\gcc\x86_64-w64-mingw32\10.3.0 C:\strawberry\c\x86_64-w64-mingw32\lib C:\strawberry\c\lib\gcc\x86_64-w64-mingw32\10.3.0
@@ -56 +55 @@
-    libperl=libperl532.a
+    libperl=libperl536.a
@@ -64 +63 @@
-    lddlflags='-mdll -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"'
+    lddlflags='-shared -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib" -L"C:\strawberry\c\x86_64-w64-mingw32\lib" -L"C:\strawberry\c\lib\gcc\x86_64-w64-mingw32\10.3.0"'
@@ -75 +73,0 @@
-    PERL_IMPLICIT_CONTEXT
@@ -91 +89 @@
-  Compiled at Jan 24 2021 15:05:42
+  Compiled at Mar 16 2023 12:09:49

shawnlaffan · 2023-03-16T09:50:03Z

Duh they're relying on ExtUtils::Depends - which is even more appalling than Win32::API (IMO).
In my experiences with EU::Depends wrt Gtk2, I came to conclude (without ever having proven it) that ExtUtils::Depends can't handle Strawberry's ".xs.dll" suffix.

Possibly, but the modules build without issue on strawberry perl 5.32 which suggests some difference in the setups is triggering the issue.

sisyphus · 2023-03-16T11:06:15Z

I still cannot get that to work, but assume it's a PEBKAC.

If you can re-run your cpanm command with verbosity turned on (cpanm -vi bareword::filehandles ...) and post the output it produces, I might be able to spot something.

Possibly, but the modules build without issue on strawberry perl 5.32 ...

Good point.

For me, the the problem arises with perl-5.34.0 - which still defines PERL_IMPLICIT_CONTEXT and includes -mdll in lddlflags. So I think we can rule them out.

According to dumpbin /EXPORTS Check.dll exports the same 3 functions (including hook_op_check) in both 5.32.0 and 5.34.0. So I think we can rule out the notion that hook_op_check() has become unreachable.

I don't know what that leaves us with ... something to chew over.

Cheers,
Rob

sisyphus · 2023-03-16T13:07:48Z

I don't know what that leaves us with ... something to chew over

I just noticed that with perl-5.32.0, the directory that contains Check.dll (or Check.xs.dll) also contains an import library named "Check.a".
However, in perl-5.34.0 and later "Check.a" is no longer present.

So, in sp536_20230316, I created that import lib using the gendef and libtool that ships with that perl and doing:

C:\strawberry\perl\vendor\lib\auto\B\Hooks\OP\Check>gendef Check.xs.dll
 * [Check.xs.dll] Found PE+ image

C:\strawberry\perl\vendor\lib\auto\B\Hooks\OP\Check>dlltool -k --output-lib Check.a --def Check.xs.def

C:\strawberry\perl\vendor\lib\auto\B\Hooks\OP\Check>

The bareword::filehandles and multidimensional builds then go fine.
So all we need to do is to work out how to build B::Hooks::OP::Check such that the import library "Check.a" is created.

That will have to wait for a while - it's getting late over here.

Cheers,
Rob

shawnlaffan · 2023-03-16T21:26:33Z

Thanks Rob.

The only .a files in the 5.36 perl dir on my local system (excluding files in the Alien::MSYS share dir since I've test installed some other stuff) are:

/strawberry/perl/lib/CORE/libperl536.a
/strawberry/perl/vendor/lib/auto/share/dist/Alien-FFI/lib/libffi.a

In contrast my 5.32 has:

strawberry/perl/lib/CORE/libperl532.a
strawberry/perl/site/lib/auto/bareword/filehandles/filehandles.a
strawberry/perl/site/lib/auto/multidimensional/multidimensional.a
strawberry/perl/vendor/lib/auto/B/Hooks/OP/Check/Check.a
strawberry/perl/vendor/lib/auto/B/Utils/Utils.a
strawberry/perl/vendor/lib/auto/Devel/Declare/Declare.a

plus a heap of Alien related files except libffi.a because Alien::FFI in 5.36 has not found the system files and has built a share install instead (that looks like the same symptoms as #71, and which could circle back to this one).

So something is missing in the compilation. Hopefully it is just a flag that needs to be added.

We might also need to recompile the extlibs, particularly if it turns out that winlibs gcc 10.3 has sufficiently different default compiler/linker flags compared with the strawberry perl gcc 8.3.

sisyphus · 2023-03-17T01:00:55Z

With my SP-5.32.1 (EU-MM-7.58) if I manually build B-Hooks-OP-Check-0.22, then Check.a does NOT get created.
When I do exactly the same with my SP-5.32.0 (EU-MM-7.46), Check.a DOES get built.

Presumably SP-5.32.1 did not actually rebuild B-Hooks-OP-Check, but just used the already-built rendition that had shipped with 5.32.0 - which is technically a fine and reasonable thing to do, given that the B-Hooks-OP-Check had not been updated.
(Or perhaps , in my SP-5.32.1, EU-MM has, at some point after the initial installation, been updated to 7.58 ... dunno.)

The difference, I think , comes down to the generated Makefiles in the 2 builds of B-Hooks-OP-Check.
Whereas, the (good) 5.32.0 Makefile contained:

# --- MakeMaker static_lib section:
# This isn't actually a static lib, it just has the same name on Win32.
$(INST_DYNAMIC_LIB): $(INST_DYNAMIC)
	dlltool --def $(EXPORT_LIST) --output-lib $@ --dllname $(DLBASE).$(DLEXT) $(INST_DYNAMIC)

dynamic:: $(INST_DYNAMIC_LIB)

the (bad) 5.32.1 Makefile has:

# --- MakeMaker static_lib section:
$(INST_STATIC): $(OBJECT) $(MYEXTLIB) $(INST_ARCHAUTODIR)$(DFSEP).exists
	$(RM_F) "$@"
	$(AR) -ru $@ $(OBJECT)
	$(CHMOD) $(PERM_RWX) $@
	$(NOECHO) $(ECHO) "$(EXTRALIBS)" > $(INST_ARCHAUTODIR)$(DFSEP)extralibs.ld

And, presumably, this change (for the worse) has stayed with us ever since.

What determines which "MakeMaker static lib section" gets written into the generated Makefile ?
On my SP-5.32.0, for some XS modules (like B-Hooks-OP-Check), the former is written to the generated Makefile - but for most XS modules it's the latter that gets written.
I would think that the solution lies somewhere in lib/ExtUtils - but I've had no luck in locating it.
Am I looking in the wrong place ?

Cheers,
Rob

shawnlaffan · 2023-03-17T01:24:40Z

FWIW, there is no special handling of B-Hooks-OP-Check in the build system. The last update on CPAN is from 2017.

The config for 5.32.0 is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/master/share/64bit-5.32.0.1.pp

There seems not to be a config file for 5.32.1 so it is hard to say what changes were made. (Edit - actually it is here if one wants to run a diff).

There is a step where any CPAN modules are updated to their latest versions. It is automated so if any of the modules it checks (dual-life core modules I think) has an update then it is picked up. Methods are here and the update script is here.

The settings for 5.32.0 are:

Perl-Dist-Strawberry/share/64bit-5.32.0.1.pp

Lines 98 to 106 in d1a3c70

    
           { 
        
               plugin => 'Perl::Dist::Strawberry::Step::UpgradeCpanModules', 
        
               exceptions => [ 
        
                 # possible 'do' options: ignore_testfailure | skiptest | skip - e.g.  
        
                 #{ do=>'ignore_testfailure', distribution=>'ExtUtils-MakeMaker-6.72' }, 
        
                 #{ do=>'ignore_testfailure', distribution=>qr/^IPC-Cmd-/ }, 
        
                 { do=>'ignore_testfailure', distribution=>qr/^Net-Ping-/ }, # 2.72 fails 
        
               ] 
        
           },

So all the above would suggest changes in EUMM?

shawnlaffan · 2023-03-17T01:25:45Z

....and ExtUtils-Install and ExtUtils-MakeMaker are both updated in the 5.36 build.

sisyphus · 2023-03-17T06:16:30Z

I'm pretty sure it's just a bug in ExtUtils::Depends-0.8001.
Reverting to version 0.8000 should fix the problem - but note that it's B::Hooks::OP::Check that needs to be built against ExtUtils-Depends-0.8000.
I don't think it matters which version of ExtUtils::Depends is found when bareword::filehandles or multidimensional is being built.

I haven't yet done the requisite fart-arsing around to prove this.
But the desired "MakeMaker static_lib section" of the generated B::Hooks::OP::Check Makefile comes straight out of version 0.8000 of ExtUtils/Depends.pm.
And that stuff has been removed from version 0.8001 of ExtUtils/Depends.pm.

Shawn, I'll do the necessary "fart-arsing around" tonight or tomorrow morning, and try to come up with a patch that repairs the damage done to version 0.8001.
In the meantime, if you manage to establish that ExtUtils-Depends-0.8001 is NOT the cause of the breakage, please let me know,

This entry in the EU-Depends "Changes" file is, I think, telling:

0.8001
    - Remove hack (cf https://rt.cpan.org/Ticket/Display.html?id=45224)
      The hijacking of EUMM's `static_lib` method is now obsolete, as well as
      causing problems.
    - Also added a couple of code tidy-ups

Obsolete ????
I haven't yet waded the referenced ticket.

Cheers,
Rob

shawnlaffan · 2023-03-17T07:34:46Z

Thanks Rob. I'll have a go at building with ExtUtils::Depends-0.8000 tomorrow.

sisyphus · 2023-03-17T08:44:45Z

Yep - LGTM.
In my own perl-5.36.0 (which had been suffering exactly the same problem):

build and install ExtUtils-Depends-0.8000
(re)build and (re)install B-Hooks-OP-Check-0.22
(re)build and (re)install bareword-filehandles-0.007 and multidimensional-0.14

I expect you'll also need to rebuild and reinstall B::Utils and Devel::Declare.

One of the Devel::Declare dependencies kept on throwing exceptions during the running of the tests because libgcc-s-seh-1.dll (which is in my path) could not be found.
Nevertheless, Devel::Declare built, tested and installed just fine.

UPDATE:
Filed a bug report against ExtUtils::Depends at https://rt.cpan.org/Ticket/Display.html?id=147200 .

Cheers,
Rob

spicyjack · 2023-03-17T16:12:54Z

I've replied with the below text to your ticket on CPAN, but I'm adding it here so that people have some context to the original problem and why the change was made to EU::Depends for 0.80001

=====
You can see the history of why the changes for 0.80001 were made in https://rt.cpan.org/Ticket/Display.html?id=45224.

I honestly don't know how to move forward with this.

It sounds like Strawberry and "other people's Windows Perl" are using two different compiler suites or versions of GCC/MinGW, but at the time we were working on this, we never asked specifically who was using what, so now that knowledge has probably moved on.

I'm fine with reverting the change for 0.80001 and cutting a release, as long as reverting this change doesn't cause RT tickets and releases that oscillate the code between "needs static_lib" and "doesn't need static_lib", which is what I think will happen.

genio · 2023-03-17T16:17:28Z

@spicyjack I'm not sure that given what you've pointed out that I'd request you make changes at this point. We'll always be dealing with different versions of GCC/MinGW due to how we have to build things for Windows at the moment. Since we know a specific version works, we can ship with that one for now.

In the future, when we release with a different version of GCC/MinGW we may not run into the same problems.

Eventually, when we start using MSVC we'll have entirely different problems.

Anybody else feel differently? I'd hate to have EUMM::Depends unfix things for Windows when each version of Perl for Windows right now ships with a different compiler version.

shawnlaffan · 2023-03-17T21:07:40Z

I'm happy to release with EUMM::Depends 0.80000.

There remains the risk (likelihood) that a user will update to 0.80001 and then hit the same issues when building other dependencies. So hopefully a satisfactory solution can be found.

@spicyjack - if it helps, the differences between the perl -V for 5.32 and 5.36dev are in this earlier comment.

No one has yet commented on those in this issue (edit - except sisyphus in #80 (comment)). There is the obvious difference that lddlflags for 5.32 start with -mdll while 5.36 has -shared. I don't know if that makes a difference, but if generating the .a files is a case of adding a flag somewhere then we can give it a go.

sisyphus · 2023-03-18T00:49:10Z

There is the obvious difference that lddlflags for 5.32 start with -mdll while 5.36 has -shared. I don't know if that makes a difference, but if generating the .a files is a case of adding a flag somewhere then we can give it a go.

AFAICS, the only thing that matters is whether auto/B-Hooks-OP-Check/Check.a exists - either in vendor/lib or site/lib (or both).
And the only way for that file to exist is to build and install B-Hooks-OP-Check against ExtUtils-Depends-0.8000 (or, presumably earlier).
So, with SP-5.32.x, you can experience the exact same issue if you:

Remove (rename) vendor/lib/auto/B-Hooks-OP-Check/Check.a
Upgrade EU-Depends to 0.8001
Rebuild and reinstall B-Hooks-OP-Check-0.22
Try to rebuild bareword-filehandles-0.007

There is currently no flag that will alter that.

@spicyjack - I don't accept that the version of gcc/mingw is relevant to this problem.
It's the same thing whenever I try to build barewords-filehandles-0.007, irrespective of the perl version or the version of gcc.
If B::Hooks::OP::Check has been built against ExtUtils-Depends-0.8001, then Check.a does not get created, and the barewords::filehandle build fails because hook_op_check() is not found.
I've tried with perl-5.24.0 (built with gcc-5.3.0), perl-5.32.0 (built with gcc-8.3.0), perl-5.34.0 (built with gcc-10.2.0) and perl-5.36.0 (built with gcc-11.3.0) and it's always the same story.
I can't find a scenario where ExtUtils-Depends-0.8001 actually allows the building of bareword-filehandles 0.007.
And the fact that everything goes fine when ExtUtils-Depends-0.8000 is used strongly suggests that the bug is in ExtUtils-Depends-0.8001.
But I'll follow that link you provided and see if I can come up with something more helpful.

@shawnlaffan - FWIW, I support the using of EU-D-0.8000 in the upcoming releases.
It seems to me that the only significant change from 0.8000 to 0.8001 is the one that has created the breakage.

UPDATE: made some corrections
Cheers,
Rob

shawnlaffan · 2023-03-18T03:42:55Z

Just an update to confirm that these modules pass when using ExtUtils-Depends-0.8000.

Crypt::OpenSSL::DSA fails tests but does now build.

The changes will be on the wip_536 branch when next I push to it.

sisyphus · 2023-03-18T04:08:39Z

I just want to add that, regarding the problem with ExtUtils-Depends-0.8001, I've reopened the original ticket at https://rt.cpan.org/Ticket/Display.html?id=45224
Although it dates from 2009 (up to 2021), its title is "Fails to link against declared dependencies on strawberry perl", which still (again ?) seems relevant.

Re-opening it might also attract the assistance of some well informed and interested parties.

Cheers,
Rob

shawnlaffan · 2023-03-18T07:31:06Z

I just want to add that, regarding the problem with ExtUtils-Depends-0.8001, I've reopened the original ticket at https://rt.cpan.org/Ticket/Display.html?id=45224

That's probably the better place for discussion of the issue. If a new version of ExtUtils::Depends is released in time for SP 5.36 then we can ship with that, but it's easy enough for users to upgrade as appropriate.

I'll open a separate issue for the Crypt::OpenSSL::DSA test failures if I can't see an easy solution.

See #80

shawnlaffan · 2023-03-18T09:25:59Z

The latest dev release includes ExtUtils::Depends 0.8000.

If anyone wants to look at #86 then that would be very useful.

shawnlaffan · 2023-04-19T08:31:49Z

All except Crypt::OpenSSL::DSA are now passing.

Crypt::OpenSSL::DSA has its own issue (#86) so closing this.

shawnlaffan added perl5.36 cpan builds labels Mar 16, 2023

shawnlaffan mentioned this issue Mar 16, 2023

perl 5.36 cpan | Devel::Declare does not build #70

Closed

shawnlaffan added a commit that referenced this issue Mar 18, 2023

5.36: install ExtUtils::Depends 0.8000

e5a3732

See #80

shawnlaffan mentioned this issue Mar 18, 2023

perl 5.36 cpan | Crypt::OpenSSL::DSA tests appear to be segfaulting #86

Closed

This was referenced Mar 18, 2023

perl 5.36 cpan | Crypt::OpenSSL::Bignum build fails #79

Closed

perl 5.36 cpan | bareword::filehandles build fails #76

Closed

shawnlaffan closed this as completed Apr 19, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

perl 5.36 cpan | several Crypt:: builds are failing #80

perl 5.36 cpan | several Crypt:: builds are failing #80

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 16, 2023 •

edited

Loading

sisyphus commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 16, 2023

sisyphus commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 16, 2023

sisyphus commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 17, 2023

shawnlaffan commented Mar 17, 2023 •

edited

Loading

shawnlaffan commented Mar 17, 2023

sisyphus commented Mar 17, 2023

shawnlaffan commented Mar 17, 2023

sisyphus commented Mar 17, 2023 •

edited

Loading

spicyjack commented Mar 17, 2023

genio commented Mar 17, 2023

shawnlaffan commented Mar 17, 2023 •

edited

Loading

sisyphus commented Mar 18, 2023 •

edited

Loading

shawnlaffan commented Mar 18, 2023

sisyphus commented Mar 18, 2023 •

edited

Loading

shawnlaffan commented Mar 18, 2023

shawnlaffan commented Mar 18, 2023

shawnlaffan commented Apr 19, 2023

perl 5.36 cpan | several Crypt:: builds are failing #80

perl 5.36 cpan | several Crypt:: builds are failing #80

Comments

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 16, 2023 • edited Loading

sisyphus commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 16, 2023

sisyphus commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 16, 2023

sisyphus commented Mar 16, 2023

shawnlaffan commented Mar 16, 2023

sisyphus commented Mar 17, 2023

shawnlaffan commented Mar 17, 2023 • edited Loading

shawnlaffan commented Mar 17, 2023

sisyphus commented Mar 17, 2023

shawnlaffan commented Mar 17, 2023

sisyphus commented Mar 17, 2023 • edited Loading

spicyjack commented Mar 17, 2023

genio commented Mar 17, 2023

shawnlaffan commented Mar 17, 2023 • edited Loading

sisyphus commented Mar 18, 2023 • edited Loading

shawnlaffan commented Mar 18, 2023

sisyphus commented Mar 18, 2023 • edited Loading

shawnlaffan commented Mar 18, 2023

shawnlaffan commented Mar 18, 2023

shawnlaffan commented Apr 19, 2023

sisyphus commented Mar 16, 2023 •

edited

Loading

shawnlaffan commented Mar 17, 2023 •

edited

Loading

sisyphus commented Mar 17, 2023 •

edited

Loading

shawnlaffan commented Mar 17, 2023 •

edited

Loading

sisyphus commented Mar 18, 2023 •

edited

Loading

sisyphus commented Mar 18, 2023 •

edited

Loading