Net::SSLeay won't build against perl compiled with g++ #425
Comments
|
I've looked into and it seems compile errors can be fixed with explicit casts from On MacOS a quick workaround that works for me is this (OPENSSL_PREFIX is needed if system OpenSSL installation should be avoided): I've tested this with Perl 5.37.8 compiled with |
…om 'void *'. C allows implicit pointer conversion to and from 'void *'. C++ does not allow this. Support C++ compilers by avoiding implicit conversion or by adding explicit cast to where conversion is needed.
…l to 'char *. In C string literals do not have the 'const' qualifier but in C++ they do. Avoid C++ compiler warnings by changing our TRACE() funciton definition to use 'const char *' instead of plain 'char *'. This is a useful change for C too because they string passed to the function can be expected to be read-only.
|
Please see if branch GH-425-cpp-patch works without The |
Thank you very much for your investigation of this problem. By producing a patch, you actually went deeper into the problem than I expected you would. I was actually simply seeking confirmation that attempting to build Net::SSLeay (from CPAN) against a Hence, you don't really need to apply your patch to keep me happy, particularly not if that would pose a maintenance burden for you down the road. (We have to be mindful of downstream packagers of Net-SSLeay as well.) If your patch does no harm, you can apply it -- but I would keep that warning in That being said, your patch does appear to work in at least one environment in which I tested it. Net-SSLeay GH-425-cpp-patch / Linux Debian 11 / CC: g++-10 / v5.37.8, threaded The Per instruction, Net::SSLeay was built with What I really like is the fact that So, since you've more than addressed my questions, you may close this ticket. Thank you very much. Jim Keenan |
I think OpenSSL is more permissive with regard to "mixing compilers" than what
The patch should be harmless to apply since it only
I've also tested on macOS with a couple of different GCC and Clang C/C++ combinations. Seems to work fine too with recent enough OpenSSL versions. Very old 0.9.8 versions have headers that trigger failures, but those are long past any reasonable support.
I'll see about adding this to compiler flags on compilers that support it (GCC and Clang probably). At some point we need consider how to properly handle OpenSSL API functions that get removed. That needs co-ordination with IO::Socket::SSL and likely other maintainers too. |
|
Thanks for the follow-up. Please ping me if I can be of further assistance. |
There seems to have been further investigation of these g++-related issues as evidenced by the discussion in #438. Will there be a new CPAN release of Net-SSLeay any time soon? To reiterate my own use-case: For testing purposes (CPANtesters and otherwise) I sometimes need to install a perl compiled with g++, then install Task::CPAN::Reporter against that perl. Since Net::SSLeay is an early prerequisite for Task::CPAN::Reporter, I would very much appreciate if Net::SSLeay built and installed smoothly against perls built with g++. Thank you very much. |
|
There's no CPAN release planned yet, but yes, it's been a while since the last release. There's at least one more feature I've almost done, TLS 1.3 client side PSK functionality, and some cleanups which I'd like to see included in the next release. Regarding this comment, does it look like a good idea to get rid of |
I don't have enough knowledge of XS or C to make an informed comment on that. |
…om 'void *'. C allows implicit pointer conversion to and from 'void *'. C++ does not allow this. Support C++ compilers by avoiding implicit conversion or by adding explicit cast to where conversion is needed.
…l to 'char *. In C string literals do not have the 'const' qualifier but in C++ they do. Avoid C++ compiler warnings by changing our TRACE() funciton definition to use 'const char *' instead of plain 'char *'. This is a useful change for C too because they string passed to the function can be expected to be read-only.
My preliminary testing of this updated code looks good. I had a perl compiled with I added your GH repository as a remote and pulled your master branch today. I built Net-SSLeay with this perl. Note the "mixing and matching compilers" warning below, as well as the multiple So, so far, so good. I request that you keep this GH Issue ticket open until a new version of Net-SSLeay is released to CPAN, since this problem first appeared during an automated installation from CPAN of a distribution (Task-CPAN-Reporter) for which Net-SSLeay is a prerequisite. Thank you very much. |
|
Thanks for the report. I'll keep issue open until the next release.
I think the "mixing and matching compilers" is no longer a problem, at least when the compilers are GCC and Clang. I'm not so sure about Windows, though. The text needs an update.
A problem with |
|
@jkeenan Earlier you mentioned that Task-CPAN-Reporter requires Net-SSLeay. Hopefully the release isn't related to http://matrix.cpantesters.org not showing anything for recently uploaded distributions. |
I have successfully compiled and installed Net::SSLeay against perls themselves compiled with g++. Output of
That is weird! I confirmed your observation and have reported it to the cpantesters-discuss mailing list. (I have no idea when that might be fixed.) |
In the OpenSSL documentation I read:
"You must use a C compiler to build the OpenSSL library. You cannot use a C++ compiler. Later, once the library is built, it is OK to create user programs with a C++ compiler. But the library proper must be built with a C compiler."
I have learned the hard way that I cannot install Net::SSLeay against a
perlbuilt withg++on systems whereopensslwas presumably built with eithergcc(Debian Linux 11) orclang(FreeBSD-12). In each case,makespewed 500 to 1200 lines of warnings before finally expiring with output like this:While I personally don't make use of
g++to compile my ownperls, in my work for Perl 5 Porters I periodically have to compileperlwithg++to explore bug reports, build-time warnings, etc. Net-SSLeay is a prerequisite to Task::CPAN::Reporter, which is what I principally use for CPANtesters reporting. But if it's useless unless the systemopensshwas built withg++or equivalent, then I can't generate CPANtesters reports if theperlwas built withg++.Am I understanding this problem correctly? Do you know of any workarounds?
The text was updated successfully, but these errors were encountered: