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

Specific shared library numbers are too restrictive #85

Open
prlw1 opened this issue Aug 19, 2016 · 4 comments
Open

Specific shared library numbers are too restrictive #85

prlw1 opened this issue Aug 19, 2016 · 4 comments

Comments

@prlw1
Copy link

prlw1 commented Aug 19, 2016

I see in dispatch_common.c that you have

# ifdef ANDROID
# define EGL_LIB "libEGL.so"
# define GLES1_LIB "libGLESv1_CM.so"
# define GLES2_LIB "libGLESv2.so"
# else
# define EGL_LIB "libEGL.so.1"
# define GLES1_LIB "libGLESv1_CM.so.1"
# define GLES2_LIB "libGLESv2.so.2"
# endif

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

@yaronct
Copy link
Contributor

yaronct commented Aug 19, 2016

@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 eglplatform.h or khrplatform.h. If you're willing to open an issue at my fork it'll b highly appreciated.

@ebassi
Copy link
Collaborator

ebassi commented Jan 30, 2017

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 dlopen() at build time, to make it easier for distributors to tweak this particular value.

@prlw1
Copy link
Author

prlw1 commented Mar 5, 2019

Bemused:

  • Why patch for android, and not expect a bug to be issued against android?
  • The full title of the linked page is "OpenGL® Application Binary Interface for Linux", which again suggests that the version with a major number be #ifdef Linux
  • The linked page states

libGL.so and libGLU.so should be symbolic links pointing to the runtime names, so that future versions of the standard can be implemented transparently to applications by changing the link.

so these don't appear to be arguments against the suggestion.

@anholt
Copy link
Owner

anholt commented Mar 5, 2019

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)

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

No branches or pull requests

4 participants