Build Error: Crypt-OpenSSL-X509 1.813 for Perl 5.28.1 on Windows

Looking for help with this package that is failing to build in my project.

Runtime Details

  • ActiveState
  • Language - perl 5.28.1
  • Platform - Windows

Failing Packages

  • Crypt-OpenSSL-X509 1.813

Reasons

  • Build failures: module Crypt-OpenSSL-X509

Hi @Renton60 - thanks for posting, I’ll check in with the builds team and let you know if there are an solutions to get this working. I will report back.

I’ve run into this too. At line 81 of the log I see:

Running [gmake]…
Warning: Aliases ‘subject_hash’ and ‘hash’ have identical values in X509.xs, line 422

X509.xs:5:10: fatal error: openssl/asn1.h: No such file or directory
#include <openssl/asn1.h>
^~~~~~~~~~~~~~~~
compilation terminated.

gmake: *** [Makefile:343: X509.o] Error 1

gmake failed: ‘gmake’ exited with value 2 at C:\builds\builder-deps\9a7c7a0e-e59b-502d-9724-6ccde2225f38\installdir\lib/ActiveState/ModuleBuilder.pm line 457.
cp X509.pm blib\lib\Crypt\OpenSSL\X509.pm

I’m importing the same set of modules that I successfully built with earlier this week. This must be a new issue.

This module isn’t one I imported, So its rather annoying that there is nothing to indicate what it was a dependency of – its not even in the log. I’m left to remove the dependencies I imported one by one until I get a build.

It would be a useful enhancement to provide some indication as to what module at the top of the dependency chain triggered a module build that failed.

@Renton60, @jgpuckering

I’ve fixed the issue which was preventing this build from succeeding, and confirmed that a fork of your project builds successfully.

1 Like

What was the nature of the problem? I’m curious to know, since this built successfully just a few days before. Was there some change introduced to the platform that somehow affected this particular build?

Also, is there any way – short of painstakingly removing every module until you get a successful build – to determine which module is the the source of another module dependency? I couldn’t tell from the logs or any other source I could find from where Crypt::OpenSSL::x509 got pulled in. Maybe I missed something.

There were two issues:

  1. We didn’t have a dependency on OpenSSL explicitly declared.
  2. The package Makefile.PL wasn’t able to locate our build of OpenSSL on Windows when it did exist.

The first issue could have its dependency satisfied if another package was pulling in OpenSSL. With the second issue, I’m surprised to hear that you previously had a Windows build succeed. Is there a project I’d be able to examine the history of?

I still have work to do in order to allow the builds to succeed in the newer Perl 5.32 builds.

For the reverse dependency issue, there’s no good way I’m aware of in the UI to determine why a package was pulled in. I can reach out to the relevant team and determine if a solution to this is on their roadmap.

@gboyce

Thank you, I installed and tested the build successfully.

1 Like

@jgpuckering At some point in the past we’d mocked up an idea to display dependencies in the UI, which I’ve pasted below. Is this the kind of view you were thinking of when looking at the Configuration tab?

It’s a bit hard for me to tell from those screenshots because everything is named package and every package has the same version number.

What I’m looking for is this. Suppose I add package Data::Printer to my build. If you look up Data::Printer on cpan, you’ll see that it has dependencies on Fcntl, File::Spec, File::Temp, Scalar::Util, Test::More, version and perhaps others.

Now lets suppose the the build fails while trying to build Fcntl. I’ll see that from the log … but I what I don’t see is that it was building Fcntl because I had asked for Data::Printer. The only way I can figure that out is to remove the modules I added one by one until the build succeeds. (Actually, what I do is a binary chop, removing half the modules each step to narrow it down so the worst case is O(log n) steps.)

And of course, that only works if the failed module was brought in by a module I added – as opposed to one that you included in the standard build or in a bundled I added.

Ultimately there needs to be a way to trace these broken things back to ancestors that caused them to be included. That way I can try removing the ancestor, or replacing it with an alternative.

I hope that helps.

1 Like