libepoxy icon indicating copy to clipboard operation
libepoxy copied to clipboard

Specific shared library numbers are too restrictive

Open prlw1 opened this issue 7 years ago • 4 comments

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

prlw1 avatar Aug 19 '16 07:08 prlw1

@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.

yaronct avatar Aug 19 '16 19:08 yaronct

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.

ebassi avatar Jan 30 '17 12:01 ebassi

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.

prlw1 avatar Mar 05 '19 15:03 prlw1

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)

anholt avatar Mar 05 '19 18:03 anholt