virtualenv doesn't work with stock Python

[jcea]

Image: base-multiarch 16.3.1

System description: SmartOS image 16.3.1 (current and fully patched).

[root@Web /tmp/z]# pkgin install py27-pip
[...]
[root@Web /tmp/z]# python -m pip install virtualenv
[...]
[root@Web /tmp/z]# python -m virtualenv VENV
New python executable in /tmp/z/VENV/bin/python2.7
Also creating executable in /tmp/z/VENV/bin/python
/tmp/z/VENV/bin/python2.7: abiexec("python2.7") failed
ERROR: The executable /tmp/z/VENV/bin/python2.7 is not functioning
ERROR: It thinks sys.prefix is u'/tmp/z' (should be u'/tmp/z/VENV')
ERROR: virtualenv is not compatible with this system or executable

[mamash]

Have you tried py27-virtualenv instead of trying to build your own?

F.

1. 10. 2016 v 2:35, jcea notifications@github.com:

Image: base-multiarch 16.3.1

System description: SmartOS image 16.3.1 (current and fully patched).

[root@Web /tmp/z]# pkgin install py27-pip
[...]
[root@Web /tmp/z]# python -m pip install virtualenv
[...]
[root@Web /tmp/z]# python -m virtualenv VENV
New python executable in /tmp/z/VENV/bin/python2.7
Also creating executable in /tmp/z/VENV/bin/python
/tmp/z/VENV/bin/python2.7: abiexec("python2.7") failed
ERROR: The executable /tmp/z/VENV/bin/python2.7 is not functioning
ERROR: It thinks sys.prefix is u'/tmp/z' (should be u'/tmp/z/VENV')
ERROR: virtualenv is not compatible with this system or executable
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[jcea]

@mamash:

[root@Web ~]# pkgin list|grep -i py27
py27-curses-2.7.12nb2 Curses module for Python
py27-expat-2.7.12    Python interface to expat
py27-mercurial-3.9.1 Fast, lightweight source control management system
py27-pip-8.1.2       Installs Python packages as an easy_install replacement
py27-setuptools-27.2.0 New Python packaging system
[root@Web ~]# pkgin search virtualenv
No results found for virtualenv

[mamash]

Ah OK, I'll have a look at why doesn't it build.

F.

1. 10. 2016 v 23:51, jcea notifications@github.com:

@mamash:

[root@Web ~]# pkgin list|grep -i py27
py27-curses-2.7.12nb2 Curses module for Python
py27-expat-2.7.12 Python interface to expat
py27-mercurial-3.9.1 Fast, lightweight source control management system
py27-pip-8.1.2 Installs Python packages as an easy_install replacement
py27-setuptools-27.2.0 New Python packaging system
[root@Web ~]# pkgin search virtualenv
No results found for virtualenv
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[mamash]

I'm fixing the problem with the virtualenv package. However, unless you have a strong reason to use a multiarch image, I'd suggest otherwise, as multiarch support for Python packages is far from solid (also explains why a lot of Python-related packages are missing in the multiarch package set).

[jcea]

So, your recommendation, @mamash, is to use a 64 bits image, I guess. I have a misc of 32 and 64 bits binaries I need to run from Solaris 10. What is the difference between 32, 64 and multiarch, exactly?

[jcea]

@mamash, asking around it is pretty clear I need to run multiarch. I need both 32 and 64 bits libraries available.

[mamash]

Typical SunOS binaries, i.e. such that only link against libs coming from the platform, will see no effect from either 32/64/multiarch image, because the platform stays the same regardless of which image you pick. However, if they link against libraries that do not come with the platform (e.g. because they were build on a SunOS system that carried such libs, but the SmartOS platform does not) and you're hoping they will be satisfied by something from pkgsrc (a risky thing, since the versions and ABI might totally off), you'll need to match.

It's easy to verify with ldd /path/to/binary. If you see any references to /opt/local, it's linking against pkgsrc. (The only one that should safe to pull from pkgsrc would be GCC libs, they come in both archs on all image flavours.)

I'm still looking into the virtualenv problem - even a fixed py27-virtualenv package will still fails on multiarch, so it's a deeper problem.

[mamash]

OK, the problem with virtualenv is that it relocates (makes a copy) the Python binary, which breaks the multiarch abiexec wrapper mechanism. To avoid the problem, in addition to /opt/local/bin/python2.7, one has to copy over the /opt/local/bin/{amd64,i86}/python2.7 (real) binaries over too.

You could do that manually, then re-run the virtualenv command, which should just resume and finish.

While it's unlikely this could be upstreamed, it should be part of the py27-virtualenv package. I'll see if I can amend it that way.

[mamash]

I almost got this working today, I'll update the ticket when the fix is in the multiarch package set.

[mamash]

I'm sorry, I forgot to update this ticket. This was fixed back in November, backported to 2016Q3 and also available in the new 2016Q4 package set.

In order to have virtualenv working on a multiarch image, you'll need to use the virtualenv packages from our pkgsrc repository. Stock virtualenv from upstream will still have no clue how to treat the multiarch isaexec wrappers and fail.