Title MacOS: can't create standalone with python 3.5 venv
Priority bug Status chatting
Superseder Nosy List Yoshi325, bitwisecook
Assigned To Keywords macos, standalone

Created on 2015-10-21.04:24:21 by bitwisecook, last changed by kayhayen.

File name Uploaded Type Edit Remove
catch_all_exceptions.patch Yoshi325, 2016-12-16.18:55:25 application/octet-stream
hello-error.txt bitwisecook, 2015-10-21.04:24:21 text/plain bitwisecook, 2015-10-21.04:25:09 text/x-python-script
remove_s.patch Yoshi325, 2016-12-16.18:55:39 application/octet-stream
msg2244 (view) Author: kayhayen Date: 2017-10-17.11:55:25
Please provide feedback. That breaking out of the virtualenv by the code below is 
msg2190 (view) Author: kayhayen Date: 2017-07-19.09:46:54
Since changing the exception handler to ignore everything is a bit invasive, I think it's better to merely 
just add "sys.real_prefix = sys.prefix" to the code in question, which will avoid that issue.

The other thing is that breaking out the "venv" ought to be done. Please check out the code in 
SingleExe.scons that follows:

# For Nuitka, it generally is OK to break out of the virtualenv, and use the
# original install. Mind you, this is not about executing anything, this is
# about building, and finding the headers to compile against that Python, we
# do not care about any site packages, and so on.

One of the methods ought to work, or one is missing, or is not working as
intended, consider this one:

# Some virtualenv created by "venv" seem to have a different structure, where
# library and include files are outside of it.

if not win_target and \
   python_version >= "3.3" and \
   os.path.exists(os.path.join(python_prefix, "bin/activate")):
    python_binary = os.path.join(python_prefix, "bin", "python")
    python_binary = os.path.realpath(python_binary)

    python_prefix = os.path.normpath(

Maybe that is not true for your platform?

msg2105 (view) Author: Yoshi325 Date: 2016-12-16.18:55:15
After changing the import_code to catch all exceptions, or removing "-s" and "-S" 
from args, or doing both, this is the result:

ld: library not found for -lpython3.5m
clang: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [hello.dist/hello.exe] Error 1
scons: building terminated because of errors.

However, there is a venv/lib/python3.5 directory that I think has the required 

What would you advise?

msg2101 (view) Author: kayhayen Date: 2016-12-13.12:19:21
Hm, also, I am not so sure that breaking out of the virtualenv is really a good 
idea. It might pick up wrong files that way. Maybe I need to come up with a 
solution that doesn't do "-s -S" at all. Please try remove that too.

msg2100 (view) Author: kayhayen Date: 2016-12-13.12:17:44
Nuitka is executing sys.executable with the current sys.path it is running, but 
with -s and -S, intended to disable parsing of "site" module.

Obviously that should allow it somewhat to break out of virtualenv, but that 
wouldn't be the problem.

I suspect, in your virtualenv, you have a "real_prefix" set to "sys" by the 

I think it's not as easy as to enable "" globally, or even to ignore it, 
but it could be that we should simply ignore errors. All that Nuitka really 
wants to know, is what files are loaded for standard library. Already 
ImportError and SyntaxError are being ignored. Can you please try out, if 
changing the catch in nuitka/ the line                       "    
except (ImportError, SyntaxError):\n" to catch all exceptions, if that would 
help your case?

msg2098 (view) Author: Yoshi325 Date: 2016-12-06.23:41:58
I am experiencing what appears to be the same problem. It might have to do with the 
virtualenv. Many of the lines in the reported output reference a path in the venv, 
however, some of them "break out" of the virtualenv and reference the base install. 
This is the same situation with the output I have. However, the venv in my case was 
created with the "--always-copy" flag, so I am at a loss as to why this is happening.
msg1804 (view) Author: kayhayen Date: 2016-02-11.11:11:51
This also looks very much like a venv issue of some sorts. The "real_prefix" 
access is not present in my Linux distutils/sysconfig and I cannot find it in 
3.5 source code, so this might be something homebrew does.

msg1803 (view) Author: kayhayen Date: 2016-02-11.09:00:13
Python3.5 is now properly supported, and standalone ought to work too. The 
"real_prefix" thing looks unknown to me. Does it still occur? Seems there is 
something that distutils does on your MacOS platform.

msg1801 (view) Author: bitwisecook Date: 2016-02-05.19:12:42
This appears to only happen when Nuitka is in a virtualenv on OSX.
msg1644 (view) Author: bitwisecook Date: 2015-10-21.04:25:09
$ cat
msg1643 (view) Author: bitwisecook Date: 2015-10-21.04:24:21
(yes, I know python 3.5 isn't supported, i have a separate 3.4 build host for actual 

$ nuitka --verbose --show-progress --show-scons --standalone > hello-
Nuitka:WARNING:The version '3.5' is not currently supported. Expect problems.
Nuitka:WARNING:There is a problem with detecting imports, CPython said:
Date User Action Args
2017-10-17 11:55:25kayhayensetmessages: + msg2244
2017-07-19 09:46:54kayhayensetmessages: + msg2190
2016-12-16 18:55:40Yoshi325setfiles: + remove_s.patch
2016-12-16 18:55:25Yoshi325setfiles: + catch_all_exceptions.patch
2016-12-16 18:55:15Yoshi325setmessages: + msg2105
2016-12-13 12:19:21kayhayensetmessages: + msg2101
2016-12-13 12:17:44kayhayensetmessages: + msg2100
2016-12-06 23:41:59Yoshi325setnosy: + Yoshi325
messages: + msg2098
2016-02-12 07:16:34kayhayensetkeyword: + standalone, macos
title: can't create standalone with python 3.5 -> MacOS: can't create standalone with python 3.5 venv
2016-02-11 11:11:51kayhayensetmessages: + msg1804
2016-02-11 09:00:13kayhayensetmessages: + msg1803
2016-02-05 19:12:42bitwisecooksetmessages: + msg1801
2015-10-21 04:25:09bitwisecooksetfiles: +
status: unread -> chatting
messages: + msg1644
2015-10-21 04:24:21bitwisecookcreate