Fix segmentation fault when building Python 3.6 image

[roadsideseb]

I'm not 100% sure what the guidelines or rules are around PRs like this, happy to make any adjustments that might be required to get this merged.

This fixes the issues reported in #160 for the Alpine build. For Python
3.6, the build succeeds but test illustrate that ctypes related test
fail with segmentation faults. This also prevents optimized builds
because they rely on a full run of the test suite.

The fix is based on the release candidate build of Python 3.6.1 in
Alpine Edge. It switches to system libraries for libffi and expat in
the same way it's used in the Alpine build
file.

[tianon]

I'm glad you found a workaround for the segfault, but I'm still not sold on --enable-optimizations -- it's a lot of additional build time with what seems like minimal benefit (as @yosifkit mentioned over in #160). It actually takes so long to build that Travis CI ends up killing the build. 😞

[roadsideseb]

@tianon I can totally understand your point about the optimizations. The segmentation fault still remains as an issue though. If you are using the regular build an run the unittest, it basically fails with the same error as described in #160.

How do you feel about removing --enabled-optimizations and --with-lto but merging the fix for the segmentation fault related to the ctypes build? I'm happy to update the PR accordingly.

[yosifkit]

There seems to be a mix of tabs and spaces throughout these changes; can you ensure to only use tabs. 🙏 Thanks!

[roadsideseb]

Of course. Sorry about that. I've updated both files with tabs.

[yosifkit]

How will these changes affect the other versions of alpine python (3.3, 3.4, and 3.5)?

[roadsideseb]

The previous version of Python 3.x seemed to have worked without similar segmentation faults. But I've just run the regression tests in the Python 3.4 container with the settings above and they behaved the same way as without. So it does seem to work either way. I haven't tested all 3 versions, though.

Do you want me to push updated Dockerfiles generated with the update.sh script and let them run on CI to test?

It would also be possible to use the docker --build-arg setting for running the unittest as part of the build process locally. For instance, adding this to the Alpine Dockerfiles:

...
ARG RUN_TESTS
...
	&& make -j$(getconf _NPROCESSORS_ONLN) \
        && if [ $RUN_TESTS ]; then LD_LIBRARY_PATH=/usr/src/python ./python -m test.regrtest; fi \
	&& make install \
...

And then running the docker command with RUN_TESTS=1 would also run the tests without modifying any of the Docker images hosted on the Hub:

docker build --build-arg RUN_TESTS=1 --tag tested-python 3.4/alpine

Would that be something that makes sense to add for testing purposes? What do you suggest as the next steps?