You have introduced unversioned library with bad name in /usr/lib*. Now it's going to make it impossible to install pypy3 alongside pypy. Please get rid of that library (keep it just inside /usr/lib*/pypy) or rename it to avoid collisions (to libpypy.so & libpypy3.so, i'd guess). Former is preferred since I don't feel like using custom library names is a good idea.
right. This is what you referred to by the bad .so name. Well while we can ponder as to why upstream never had the sense to foresee this, perhaps that point is moot. It's yet something else that they mis-designed and 'we' have to rectify. On my part I thought just renaming it to what suits 'us', or what looks sane to 'us', would break by mis-matching what the makers of pypy in their eyes decided was fine. I consider this quite valid and needs dealing with, or 'fixing'. So what ought 'we' re-name it to? and on that thought, does this not warrant an upstream bug to the makers of pypy to do exactly this and save us the merry dance? Surely they could have / should have given it such a name in the first place. I would have thought irc was fine but nm. Let's do it here
oh, and on that. It's official that the makers of pypy are in fact shortsighted. There has been a bug submitted to their bugzy with this exact problem, the clashing of naming files making it impossible to install, or in our case emerge, pypy2 aside pypy3. And this was done BEFORE I did the introducing of the unversioned library with bad name in /usr/lib*. which, correct me if I'm wrong, I did in reply to the bug that requested the addition of that new shared lib, which was in the recent bump only. Perhaps in this case it's just as well to unwind its addition and say sorry user, adding it caused unnecessary but forseeable problems, or breakage, that it shouldn't. But it looks as if we can leave it in and make a fix for this bug. If not, I'd go for unwinding its addition and expressing regret to the user with a couple of lines explanation.
I think it is reasonable to install the shared library in /usr/lib/pypy. This would allow users to link with it by setting LDPATH or passing -L/usr/lib/pypy to the linker. I do not think we should install it in /usr/lib without a well-defined soname that is defined by upstream for binary compatibility between releases. In other words, remove this line from the ebuild and I think we will be all set on this for the time being. dosym ../$(get_libdir)/pypy/libpypy-c.so /usr/$(get_libdir)/libpypy-c.so
Actually, is seems we are installing a pypy binary which is linked against libpypy-c.so, so the library needs to be somewhere in LDPATH or we will get this: pypy: error while loading shared libraries: libpypy-c.so: cannot open shared object file: No such file or directory
We can either set RPATH in the executable or install a wrapper.
(In reply to Michał Górny from comment #5) > We can either set RPATH in the executable or install a wrapper. Right. We discussed setting rpath in #gentoo-python, and Arfrever came up with a patch which Ian is testing.
*pypy-2.3.1-r1 (15 Jul 2014) 15 Jul 2014; Ian Delaney <idella4@gentoo.org> +files/2.3.1-shared-lib.patch, +pypy-2.3.1-r1.ebuild, -pypy-2.3.1.ebuild: revbump; patch to fix shared lib issue of libpypy-c.so wrt Bug #517002, thanks to Arfrever for the patch which is submitted upstream Preliminary testing looks fine however I shall leave it open for any further finding or suggestion since any move ahead needs this being set right.
