-
Notifications
You must be signed in to change notification settings - Fork 161
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
Specific shared library numbers are too restrictive #85
Comments
@prlw1: This repository of Epoxy seems to b currently no longer maintained. I try to maintain a fork of Epoxy - other than being maintained, it also contains a number of bug fixes and improvements, notably it can be built as a static or shared library using cmake, including running tests, and doesn't depend on |
The name of the shared objects is defined in the OpenGL ABI specification. I have no idea why NetBSD seems to think that bumping the soname is a good thing, especially to a number that does not exist in any additional specification for unvendored platforms. I would strongly recommend to file a bug against NetBSD and ask them to use the appropriate shared library name. If they don't want to, I'm sure NetBSD can ship a very simple vendor patch for Epoxy. OpenGL ES is a bit more complicated, but in general that's up to specific vendors to decide the ABI of the platform; on Mesa (which is used on various flavours of Linux and Unix) the GLES libraries usually include the ABI version in the soname. Considering that there are more Android deployments than NetBSD ones, as far as I know, I'm not particularly keen on adding an exception there. Having said that, I'd be amenable to a pull request that added the ability to specify the shared library to |
Bemused:
so these don't appear to be arguments against the suggestion. |
We should absolutely be using an ABI number, and the android thing is an unfortunate workaround for android ABI being a disaster. Hopefully NetBSD is sane and has been stable at whatever their number is for a long time, and we can just have one extra #ifdef for NetBSD's number being unusual. (I don't know why they would have diverted from Linux's ABI, since any divergence on the BSDs I considered to be a bug back when I was maintaining Mesa for FreeBSD) |
I see in dispatch_common.c that you have
In other words, if on android, don't specify the major number, but otherwise do.
Maybe that should be, when on linux, specify the major number, otherwise don't?
I have the same issue with libGL.so: on my system, the major number is 2, so keep having to patch dispatch_common to remove the .1 - maybe you want to keep the .1 in
#ifdef __LINUX__
?e.g.: http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/graphics/libepoxy/patches/patch-src_dispatch__common.c
The text was updated successfully, but these errors were encountered: