This seems like an issue with xamarin mono project, not .NET

Seems like a shame to have it always turned off, for a small percentage of PythonNET users

Why not do some sort of check for Linux or darwin, then disable, but if win32 use flag?

@mikofski can you please explain how Mono is to blame in more details, especially if you can point to specific code?

@tonyroberts @filmor @vmuriart please review. Note that I marked this pull request as release-blocking.

This change may fix a problem for some cases, but it will break it for others.

If that flag isn't reliable because of a bug in some distributions, why not check another way instead of ignoring it? Checking the output of ldd on the Python executable would tell you if it's been linked dynamically or not.

@tonyroberts @filmor this was a bit of learning for me. See analysis below.

On Linux Mint it shows that python 2/3 are dynamically linked:

Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.sysconfig import get_config_var
>>> get_config_var("Py_ENABLE_SHARED")
1

Python 3.4.3 (default, Sep 14 2016, 12:36:27) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.sysconfig import get_config_var
>>> get_config_var("Py_ENABLE_SHARED")
1

here is the output of ldd on Linux Mint with python 2/3:

dta@dta-Inspiron-N5050 ~ $ ldd `which python`
	linux-vdso.so.1 =>  (0x00007fff7e9ec000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f60536ed000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6053328000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6053123000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f6052f20000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6052d07000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6052a00000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f605392e000)
dta@dta-Inspiron-N5050 ~ $ ldd `which python3`
	linux-vdso.so.1 =>  (0x00007fff1a6e3000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd057cb8000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd0578f3000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd0576ee000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fd0574eb000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fd0572c1000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd0570a7000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd056da1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd057ef9000)

According to this wiki this most likely means that python2/python3 were build dynamically:

https://wiki.python.org/moin/BuildStatically

I tried ldd with statically build python from source and indeed it shows the correct message:

cd ./Python-2.7.12/
./configure --disable-shared LDFLAGS="-static -static-libgcc" CPPFLAGS="-static"
make LDFLAGS="-static" LINKFORSHARED=" "
ldd ./python 

with output:

not a dynamic executable

The problem is that even when python is dynamically linked, import clr fails! Most likely this is because the dynamic resolution is different from the expected. But forcing PYTHON_WITHOUT_ENABLE_SHARED works great. Supposedly there is a fix with setting LD_LIBRARY_PATH, but this changes Linux settings system-wide.

@tonyroberts so can you give examples on which Linux systems and how this would still fail?

@denfromufa Some versions of the Python executable are built with the python runtime embedded in them, and others are built with it as an external shared object (.so) file. For the ones that use a separate .so file, extensions like clr must also be built to use the same shared object. Ones that embed that code into the python executable must have extension modules built slightly differently (hence the Py_ENABLED_SHARED option, which should be set if a shared object is used).

ldd shows you the shared libraries an executable depends on. If Python has been built to use a shared object version of the python runtime will see libpythonXX.so in the list of shared object dependencies.

To build a version of Python that uses this shared object you should use the "--enable-shared" option when configuring. If successful, when you do ldd on python you will see libpythonXX.so in the output, and if you try the tests with clr built with PYTHON_WITHOUT_ENABLE_SHARED defined it will fail.

Building Python for static linking is something different. This is only useful for embedding Python into another executable without having dynamic link dependencies.

@tonyroberts great explanation, I will try to build with "--enable-shared" and do some testing.

@tonyroberts @filmor please review