Cannot install pypy v5

[Themanwithoutaplan]

Just tried to upgrade pypy and it fails with this in the log:

:info:build [translation:info]     return callb(*args)
:info:build [translation:info]    File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/pypy/work/pypy-5.0.0-src/rpython/rtyper/lltypesystem/ll2ctypes.py", line 1306, in __call__
:info:build [translation:info]     cfunc = get_ctypes_callable(self.funcptr, self.calling_conv)
:info:build [translation:info]    File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/pypy/work/pypy-5.0.0-src/rpython/rtyper/lltypesystem/ll2ctypes.py", line 1243, in get_ctypes_callable
:info:build [translation:info]     clib = dllclass._dlltype(libpath, **load_library_kwargs)
:info:build [translation:info]    File "/opt/local/lib/pypy/lib-python/2.7/ctypes/__init__.py", line 367, in __init__
:info:build [translation:info]     self._handle = _ffi.CDLL(name, mode)
:info:build [translation:ERROR] OSError: Cannot load library /usr/local/lib/libexpat.dylib: dlopen(/usr/local/lib/libexpat.dylib, 2): no suitable image found.  Did find:
:info:build [translation:ERROR]         /usr/local/lib/libexpat.dylib: mach-o, but wrong architecture
:info:build [translation] batch mode, not calling interactive helpers
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_pypy/pypy/work/pypy-5.0.0-src/pypy/goal" && arch -x86_64 /opt/local/lib/pypy/pypy ../../rpython/bin/rpython --batch --verbose --cc=/usr/bin/clang --opt=jit --make-jobs=1 targetpypystandalone
:info:build Exit code: 1
:error:build org.macports.build for port pypy returned: command execution failed
:debug:build Error code: CHILDSTATUS 68564 1
:debug:build Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"portbuild::build_main org.macports.build"
    ("eval" body line 1)
    invoked from within
"eval $procedure $targetname"

Installed pypy v4 for the first time the other day so a bit of a head-scratcher.

[seanfarley (Sean Farley)]

Huh. Can you deactivate pypy 4 (sudo port deactivate pypy) and try again?

[seanfarley (Sean Farley)]

Another user reported an error so I added a conflicts_build setting in r146539. Hopefully that will provide a better error.

[jmroot (Joshua Root)]

Couple things:

1. How exactly is this caused by the previous version of pypy being active? Reporter, can you confirm that this is the case?
2. If that's the case, wouldn't that be a miscompilation of the previous version that would affect other uses of it? Do we know the current version doesn't miscompile the same way under the same circumstances?
3. If this is caused by the old version not working properly (rather than its mere presence somehow breaking the new version's build system), then conflicts_build is a user-unfriendly approach in any case, as you could instead just build with cpython in all cases.

[jmroot (Joshua Root)]

Replying to sean@…:

Another user reported an error

I just read the thread on macports-users and I assume that's what you're referring to. That was due to openssl removing symbols and this ticket appears to be something different.

Reporter, please attach your complete log.

[seanfarley (Sean Farley)]

While it's true that error was about OpenSSL symbols, the real bug is that pypy is using $prefix/bin/pypy instead of being sandboxed.

[jmroot (Joshua Root)]

That's not a bug, it is (or was) explicitly requested in the Portfile.

[Themanwithoutaplan]

@jmr the port built without errors and the log was overwritten. But I'm including the log from the failed build.

[Themanwithoutaplan]

Log of failed build of PyPy 5

[jmroot (Joshua Root)]

I guess the ctypes search paths in the previous version must have been different to what we want. I can't see how this could have happened looking through the code, but I removed some incorrect search paths in r146609 (even though they shouldn't have been used anyway AFAICT).

Since it's working for you now, we'll call this closed. You probably still want to get rid of that non-x86_64 expat you have in /usr/local though.