Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential issues with package binaries on Linux #45

Closed
almarklein opened this issue Jan 21, 2020 · 7 comments
Closed

Potential issues with package binaries on Linux #45

almarklein opened this issue Jan 21, 2020 · 7 comments

Comments

@almarklein
Copy link
Contributor

almarklein commented Jan 21, 2020

I meant to test out the latest version on Linux (Ubuntu 19.10), because I suspected there might be an issue on Wayland, but ran into an issue. pip install glfw will take the tar.gz instead of the wheel. Pointing pip directly at the wheel gives me glfw-1.10.1-py2.py3-none-manylinux2010_x86_64.whl is not a supported wheel on this platform. So it looks like there's a flag somewhere there that prevents it from being used. I tried with pip 18.x and 20.0.1. Have you looked at auditwheel to verify/repair these wheels?

edit: the below turns out not to be an issue
I could therefore not test the potential issue I was looking into, so I'll just describe it. I can have a look later if needed. If the binary glfw lib that comes packaged is preferred over the system library, it will probably fail on Wayland (because it needs a differently compiled lib). The user can of course use PYGLFW_LIBRARY but that's annoying.

The README says that you can use the system library by installing it, but library.py seems to prefer the packaged lib instead, but I may be wrong here.

None of these are pressing issues, BTW :)

@FlorianRhiem
Copy link
Owner

The issue seems to be with the wheel tags, as those only seem to support specific python versions and not py3 when manylinux2010 is used (py3-none-any and py36-none-manylinux2010_x86_64 both work). I think those used to be supported, but I'll have to look into this. If they don't work, I might have to use something like py2.py27.py3.py30.py31.py32.py33.py34.py35.py36.py37.py38 which would be more than a little silly...

The wheels are not pure manylinux2010 wheels as glfw requires more X11 libraries than manylinux2010 provides. See this issue for a discussion about that. As I don't think providing an alternative/supplementary set of X11 libraries is a good idea (due to the potential for conflicts and weird, hard-to-debug issues), the wheels do not provide these X11 libraries. This means that, when the wheels are installed, the included GLFW library might not be usable. In that case the user can either install the missing X11 libraries, install the system GLFW (which will most likely provide the missing X11 libraries as well) or install GLFW from source (which will also mean that they'll install the missing X11 libraries).

On Linux, each library that is found is loaded in a subprocess and its version is queried. Then, the library with the largest version tuple is used. If a library cannot be loaded, it is not considered further, as it cannot be used anyway. The search path order only becomes relevant if several package provide the exact same largest version tuple. As a result, the packaged library should not cause any problems if they cannot be loaded. So the second issue you're describing should not occur. If this does not work as intended, please let me know!

@FlorianRhiem
Copy link
Owner

Yes, this used to work in pip 19.3.1, it's probably related to this issue and this issue, which were caused by the switch from pip-internal tags to packaging tags, that seems to have broken plenty of binary wheels. I'll have to see whether this is something they plan to fix or whether I'll have to go with that silly wheel name instead.

@almarklein
Copy link
Contributor Author

We're facing similar problems (pypa/pip#7636).

On Linux, each library that is found is loaded in a subprocess and its version is queried. Then, the library with the largest version tuple is used. If a library cannot be loaded, it is not considered further, as it cannot be used anyway.

Ah, I've missed that. That's great! 👍

@FlorianRhiem
Copy link
Owner

FlorianRhiem commented Jan 22, 2020

The issue seems to be fixed in master of pypa/packaging, but until that's released and used by pip the silly wheel name will have to do. I've uploaded the additional wheels to PyPI and I hope they will be used now. At least on Ubuntu:19.04 it works.

The included library might not work with Wayland, however, as I'm building them on a fairly minimal system (the manylinux2010 image with additional libXinerama, libXrandr, libXcursor and libXi). As a result, Wayland support will be missing. As the version tuples of the two libraries will be equal, the search path order might actually cause a problem in this case and PYGLFW_LIBRARY might have to be used. It'd be great if you could test this to confirm that this problem occurs. If it does, I'll have to think about reordering the search paths or finding an alternative solution.

Edit: the problem I'm describing would be on a system that has the required X11 libraries installed, but uses Wayland. A system without the X11 libraries listed above would not be able to load the packaged library.

@almarklein
Copy link
Contributor Author

  • pip install glfw on 19.04 picks the wheel.
  • It prefers the system library over the lib that is shipped with pyglfw.
    • This means that on X11, it does not matter if I have the system lib installed, it works either way.
    • On Wayland I must apt install libglfw3-wayland
    • Pyglfw produces a very informative warning when in Wayland, and the system lib is not installed :)

@FlorianRhiem
Copy link
Owner

Thank you for testing this!

That's how it should work. Of course it'd be ideal if it would work out-of-the-box on wayland, too, but I'll open a new issue for that.

@almarklein
Copy link
Contributor Author

For reference: #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants