py-m2crypto conflict with openssl-devel (really swig vs. system headers) resolved

[Kubilay Kocak]

On 24/09/2018 6:08 pm, Viktor Dukhovni wrote:
> In /etc/make.conf I have:
> 
>     DEFAULT_VERSIONS=python=2.7 python2=2.7 python3=3.3 ssl=openssl-devel
> 
> since I want OpenSSL 1.1.0 for most of the ports I build.  However, this
> disables the py2-m2crypto port, whose Makefile contains:
> 
>     BROKEN_SSL=    openssl-devel
>     BROKEN_SSL_REASON_openssl-devel=       Error: Syntax error in input(1).
> 
> I commented those out, and tried to build, and indeed the build
> fails with an error from swig3.0:
> 
>     /usr/local/bin/swig3.0 -python -I/usr/local/include -I/usr/local/include/python2.7 \
>       -I/usr/local/include -I/usr/local/include/openssl -I/usr/bin/../lib/clang/4.0.0/include \
>       -I/usr/include -includeall -modern -builtin \
>       -outdir /usr/ports/security/py-m2crypto/work-py27/M2Crypto-0.30.1/M2Crypto \
>       -o SWIG/_m2crypto_wrap.c SWIG/_m2crypto.i
>     /usr/include/x86/_types.h:67: Error: Syntax error in input(1).
> 
> I got curious as to what if anything OpenSSL 1.1.0 has to do with
> this, and it turns out that its only sin is to "#include <stdint.h>"
> in <openssl/e_os2.h>, which should cause no problems.  But it turns
> out that this runs into:
> 
>     https://github.com/freebsd/freebsd/blob/master/sys/x86/include/_types.h#L65
> 
>     __extension__
>     typedef	long long		__int64_t;
>     __extension__
> 
> with the unexpected "__extension__" giving "swig3.0" indigestion.
> 
> The unrecognized syntax in <x86/_types.h> is the real problem, and
> either FreeBSD needs a "swig" that can deal with this, or the headers
> need to be more compatible with the existing "swig".
> 
> Testing with the "__extension__" lines removed, however runs into
> another problem:
> 
>     /usr/include/sys/_types.h:104: Error: Syntax error - possibly a missing semicolon.
>     error: command '/usr/local/bin/swig3.0' failed with exit status 1
> 
> This time "swig" chokes on:
> 
>     typedef struct {
> 	    long long __max_align1 __aligned(_Alignof(long long));
> 	    long double __max_align2 __aligned(_Alignof(long double));
>     } __max_align_t;
> 
> where I assume it does not understand the "__aligned" macro.  Bottom
> line, the internal system C-header files are much too exotic for
> swig, and OpenSSL 1.1.x is rather a bystander, with previous releases
> working with m2crypto somewhat by accident.
> 
> I managed to find a solution that does not modify <openssl/e_os2.h>,
> but rather comments out the switch "-includeall" option from
> M2crypto's setup.py:
> 
>         self.swig_opts.extend(['-I%s' % i for i in _get_additional_includes()])
>         # self.swig_opts.append('-includeall')
>         self.swig_opts.append('-modern')
>         self.swig_opts.append('-builtin')
> 
> and adds a couple of additional explicit include files to SWIG/_m2crypto.i:
> 
>     %include <openssl/e_os2.h>
>     %include <openssl/stack.h>
> 
> above:
> 
>     %include <openssl/safestack.h>
> 
> With this, py-m2crypto builds with OpenSSL 1.1.x and the system
> header files unmolested.  If the maintainer of the py-m2crypto port
> is not on this list, please forward to the right person.  It would
> be good to remove this roadblock to using "openssl-devel" (since
> actually OpenSSL 1.1.1 is now an LTS release, and 1.0.x will be EOL
> at the end of 2019, so "devel" is not really the best label anymore).
> 
> Perhaps the changes could also go to the upstream maintainer of
> m2crypto.
> 

I also note that there is an open bug report for the issue:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229019