Date: Mon, 24 Sep 2018 20:21:13 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: ietf-dane@dukhovni.org, freebsd-python@freebsd.org Cc: Sunpoet Po-Chuan Hsieh <sunpoet@FreeBSD.org> Subject: Re: py-m2crypto conflict with openssl-devel (really swig vs. system headers) resolved Message-ID: <09268fc4-84d0-5f6c-9fe1-55b12c26624e@FreeBSD.org> In-Reply-To: <20180924080803.GK3589@straasha.imrryr.org> References: <20180924080803.GK3589@straasha.imrryr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > Hi Viktor, Thanks for all of the context and detail. Reporting the issue upstream (to swig [1]) would be great in the first instance, if it hasn't already been. I've CC'd the m2crypto/swig ports maintainer here so they're notified as well. Both of us would be happy to commit the reported workaround if upstream is confident that that is the best solution in the meantime (until a new release). It would be great to get their input in any case. [1] https://github.com/swig/swig/issues ./koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09268fc4-84d0-5f6c-9fe1-55b12c26624e>