From owner-freebsd-python@freebsd.org Mon Sep 24 08:08:05 2018 Return-Path: Delivered-To: freebsd-python@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DF4510A6001 for ; Mon, 24 Sep 2018 08:08:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FEA7739F3 for ; Mon, 24 Sep 2018 08:08:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 306103038DE; Mon, 24 Sep 2018 04:08:04 -0400 (EDT) Date: Mon, 24 Sep 2018 04:08:04 -0400 From: Viktor Dukhovni To: freebsd-python@freebsd.org Subject: py-m2crypto conflict with openssl-devel (really swig vs. system headers) resolved Message-ID: <20180924080803.GK3589@straasha.imrryr.org> Reply-To: ietf-dane@dukhovni.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 08:08:05 -0000 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 " in , 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 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 , 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 %include above: %include 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. -- Viktor.