Thank you for having a look.

It's really sad that such a small involvement is put in such a terrific tool (I got great speed-ups compared to python3).

Just to be precise, my report is based on pypy-c-jit-79909-4fa19970ddeb-linux64 (currently the latest), and the exact error is:

ofir@psl-12core-server:~/pypy-c-jit-79909-4fa19970ddeb-linux64/bin$ ./pypy3.3
debug: OperationError:
debug: operror-type: ImportError
debug: operror-value: No module named 'encodings'
debug: OperationError:
debug: operror-type: AttributeError
debug: operror-value: stdout

(both for pypy3 and pypy3.3 executables)

Thanks,

Ofir

On 7 October 2015 at 14:26, Armin Rigo <arigo@tunes.org> wrote:

Hi Ofir,

On Wed, Oct 7, 2015 at 10:51 AM, Ofir Shwartz <ofirshw@gmail.com> wrote:
> Is there any update on that matter?
> I tried it now and got the same results for the most updated jit and no-jit
> pypy3.3.

I looked into it a bit more. (I think it's sad that no-one had a look
since June, but I suppose it just shows that our pypy3 involvement is
rather thin.) The problem is not that the archive is incomplete; it
is complete as far as I can see. The problem is that the binary only
works if it runs inside a directory with exactly the same name as it
was compiled with.

The crash I get is in _getfilesystemencoding, called from
pypy/module/sys/__init__py:startup(). It is indeed extremely early,
before we have got any chance to set up sys.path correctly. I tried
to fix the problem but gave up after hitting several nested issues.
The failing check is pushed in 88a921f5ae6b; somebody please fix it
:-)

A bientôt,

Armin.