opengl-update script makes libMesaGL a symlink to libGL and libMesaGLU a symlink to libGLU. This is not correct if libGL currently used is not Mesa implementation: libGL is OpenGL library while libMesaGL is Mesa3D library. If an application wants to use OpenGL it links against libGL. OTOH, it if wants to use Mesa (and *not* OpenGL), it links against libMesaGL. There are legitimate reasons to insist on Mesa, for example if the app uses libOSMesa (which is a library that makes it possible to render into memory buffer w/o having to access X server -- I use it in a compression library that runs /wo X), it has to use libMesaGL because libOSMesa (naturally) doesn't work with non-Mesa implementation of OpenGL. Correct behaviour would be to install libMesaGL(U) symlink only if the implementation provides it (i.e. is Mesa-based: either Mesa or XFree).
Seems like this could provide problems for applications built when opengl-update xfree, then attempted to be used with opengl-update ati (or similar). Should the solution be not having such a symlink at all, or leaving it symlinked to xorg/xfree's libMesaGL regardless of where the other symlinks are?
> Seems like this could provide problems for applications built when > opengl-update xfree, then attempted to be used with opengl-update > ati (or similar). Sorry, I don't understand -- what kind of problems and why? No matter what happens to libMesaGL, it wouldn't affect apps that build against libGL... > Should the solution be not having such a symlink at all, or leaving it > symlinked to xorg/xfree's libMesaGL regardless of where the other symlinks > are? Yes, that's what I meant (but formulated it badly): it certainly should not be a symlink, it should be the real Mesa library (and if XFree installs libMesaGL as symlink, then the symlink should be modified to always point to XFree version). Basically, it shouldn't be managed by opengl-update and it should be available even if you selected different driver by running e.g. opengl-update nvidia. It would also be nice to be able to install latest Mesa independently of XFree, but that's a different topic (see Mesa 5.0/6.0 bugs in bugzilla). Or maybe a solution would be to remove libMesaGL from XFree ebuild (that is, leave it there under the libGL name only) and provide libMesaGL in independent ebuild -- that way OpenGL apps would still be able to use XFree's Mesa implementation as libGL, but apps that require real (software) Mesa3D would have to depend on a new Mesa ebuild. The only situation when this could be a problem would be if some apps/configure scripts incorrectly assume that OpenGL implementation on Linux is always Mesa and would require libMesaGL instead of libGL, but I don't know of any such app.
ajax, could you say something here?
libMesaGL is supposed to implement OpenGL. The library just used to be named differently. We should still have this symlink in case old applications are being built which use -lMesaGL instead of -lGL
Ad comment #4: You're wrong. Mesa3D implements SUPERSET of OpenGL (as you could easily check for yourself, if you did carefully read the original bug report and then downloaded Mesa3D and verified that it indeed contains libOSMesa API). Please check the facts before claiming what Mesa3D is "supposed" to be. Obviously, the only way to use the Mesa3D APIs that are not part of OpenGL standard is to link against libMesaGL (which, as the name suggests, should be *Mesa* library), because libGL can be *any* OpenGL implementation and there's no reason to believe it's Mesa one. As for "old applications" argument, you got it all backwards: the only way to ensure that *all* "old" applications that link against libMesa3D continue to work is to *not* make the symlink, because these "old" applications may be using non-OpenGL parts of Mesa3D, in which case they would break because the fake Gentoo is forcing on them doesn't contain what it's expected to contain. Rest assured that the Mesa folks know what they're doing and the libMesaGL name is no historical accident. To sum in up, Gentoo has good intentions of trying to fix alleged old apps that say they want to use Mesa3D, but they really want to use OpenGL. Unfortunately, the accomplished effect is that of breaking applications whose authors know their job and when they say they need libMesaGL, they *do* need it.
Jeremy, wanted to make sure you saw comment #5.
Vaclav: The fact that it extends on OpenGL is not the issue for me here... The problem is that some older software links against libMesaGL instead of libGL because there used to be no libGL (I think they started using that name sometime around 2000). Those programs don't need the extentions that Mesa added.
> Vaclav: The fact that it extends on OpenGL is not the issue for me here... That's very much obvious :( Unfortunately other people use Gentoo too and I just don't understand how could anybody consider "*I* don't care" a valid reason to break the distribution for use cases that you personally have no interest in. > The problem is that some older software links against libMesaGL instead of > libGL because there used to be no libGL (I think they started using that name > sometime around 2000). Those programs don't need the extentions that Mesa > added. 1) These programs *will* work when then link to Mesa3D instead of OpenGL, won't they? They may be slower, but they won't break. 2) If you insist on using OpenGL for them, it's perfectly possible to fix these programs instead. If they come with source code, then trivially by fixing the makefiles. If they don't, then using LD_PRELOAD=libGL.so -- a simple wrapper script would do the job, without having to break the distribution. I understand the using libOSMesa is a corner case, but so is the case you talk about, so why not fix both of them if it's possible, instead of fixing the one you are personally interested in and completely breaking the other one?
I'm not saying I don't care. I'm saying that there are two issues here, and unfortunately accomidating them is mutually exclusive. > 1) These programs *will* work when then link to Mesa3D instead of OpenGL, > won't they? They may be slower, but they won't break. Yes, that is... they will be linking to the wrong library. > If they don't, then using LD_PRELOAD=libGL.so -- a simple wrapper script > would do the job, without having to break the distribution. Good point... in fact I believe that if they do use the Mesa extensions, then doing LD_PRELOAD=/path/to/hardware/libGL.so <program that uses mesa extensions> may still work depending on how it is implemented... Do you know of any such programs that I could check this out with? > I understand the using libOSMesa is a corner case, but so is the case you > talk about, so why not fix both of them if it's possible, instead of fixing > the one you are personally interested in and completely breaking the other > one? Good point... now the problem here is that the --soname of the MesaGL library is still libGL.so.1, so ldconfig will create libGL.so.1 -> libMesaGL.so if we try to mix these. what we could do is something like this: ld -shared --soname libMesaGL.so.1 -L /usr/${LIBDIR}/opengl/xorg-x11/lib -R /usr/${LIBDIR}/opengl/xorg-x11/lib -lGL -o libMesaGL.so.1 ln -s libMesaGL.so.1 /usr/${LIBDIR}/libMesaGL.so Vaclav: What do you think of that solution?
opengl-update has a fix for this in 2.1_pre1's preinst, but it should also be added to xorg-x11 ebuilds. spyderous, please add this somewhere appropriate in xorg-x11's src_install(): $(tc-getCC) -shared -Wl,--soname,libMesaGL.so,-L,${D}/usr/$(get_libdir)/opengl/xorg-x11/lib,-R,/usr/$(get_libdir)/opengl/xorg-x11/lib -lGL -o /usr/$(get_libdir)/libMesaGL.so Demonstrations: (16:54:50 Mon Jan 24 2005 root@cid x86_64) /usr/lib32 $ opengl-update nvidia * Switching to nvidia OpenGL interface ... >>> Regenerating /etc/ld.so.cache... * Caching service dependencies ... [ ok ] (17:00:13 Mon Jan 24 2005 root@cid x86_64) /usr/lib32 $ ldd /usr/lib32/libMesaGL.so linux-gate.so.1 => (0xffffe000) libGL.so.1 => /usr/lib32/opengl/xorg-x11/lib/libGL.so.1 (0x55558000) libc.so.6 => /lib32/tls/libc.so.6 (0x55601000) libpthread.so.0 => /lib32/tls/libpthread.so.0 (0x55718000) libXxf86vm.so.1 => /emul/linux/x86/usr/X11R6/lib32/libXxf86vm.so.1 (0x5572a000) libXext.so.6 => /emul/linux/x86/usr/X11R6/lib32/libXext.so.6 (0x5572f000) libX11.so.6 => /emul/linux/x86/usr/X11R6/lib32/libX11.so.6 (0x5573e000) libdl.so.2 => /lib32/libdl.so.2 (0x5580a000) /lib/ld-linux.so.2 (0x56555000) (17:00:22 Mon Jan 24 2005 root@cid x86_64) /usr/lib32 $ ldd /usr/lib64/libMesaGL.so libGL.so.1 => /usr/lib64/opengl/xorg-x11/lib/libGL.so.1 (0x0000002a95659000) libc.so.6 => /lib/tls/libc.so.6 (0x0000002a95841000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0000002a95a67000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x0000002a95b7d000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0000002a95c82000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0000002a95d93000) libdl.so.2 => /lib/libdl.so.2 (0x0000002a95f75000) /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
whoops... not quite... here it is: $(tc-getCC) -shared -Wl,--soname,libMesaGL.so,-L,${D}/usr/$(get_libdir)/opengl/xorg-x11/lib,-R,${ROOT}/usr/$(get_libdir)/opengl/xorg-x11/lib -lGL -o ${D}/usr/$(get_libdir)/libMesaGL.so
That is something that should definitely be happening on an upstream level.
but AFAIK, upstream has decided to change the --soname to libGL.so which makes it incompatible with nvidia... so I'm just gonna get out of this right now as it's not really something I'm too concerned with... but at the least, remove the /usr/$(get_libdir)/x11-org/lib/libMesaGL.so symlink from being created...
ajax can you offer some opinion on this crap?
jeremy's comment is worrisome. on what platform are we getting the soname wrong? the linux opengl ABI requires that to be libGL.so.1: http://oss.sgi.com/projects/ogl-sample/ABI/index.html my understanding is that the libMesaGL name is vestigial and should not be used, for both ABI and legal reasons. if you need OSMesa, then your LD_LIBRARY_PATH should point at Mesa's libGL.
let's clarify this further: Mesa does not, under any circumstances, create a library named MesaGL. has not done so in many years now. old applications that link against libMesaGL are broken and have had over five years to fix themselves (when the ABI was finalized). none of the install targets in Mesa create a library or symlink by this name. features implemented as OpenGL extensions (ie, things listed by glxinfo) _must_ be checked by the app at runtime. that's just how GL works. the OSMesa interface is not an OpenGL extension but rather a Mesa-specific API extension. apps that need it should link against libOSMesa16 or libOSMesa32 as appropriate. this does not handle detecting that the supplied libGL is Mesa; for that, the _application_ needs to call glGetString(GL_RENDERER) and check that it matches "Mesa X11" (or possibly just "Mesa" as a substring). the application is responsible for failing sanely in this case. as a workaround, the runtime environment can change LD_LIBRARY_PATH to point at a Mesa implementation of libGL, or do the LD_PRELOAD trick, or the crazy indirection DSO that jeremy described. these are workarounds; they are not good default behaviour. comment #5 is false on its face: "Obviously, the only way to use the Mesa3D APIs that are not part of OpenGL standard is to link against libMesaGL". no, the correct way is to check for Mesa functionality at runtime; this is why GL has _extensive_ runtime capability reporting. new applications linking against libMesaGL are _broken_.
ok, great... then let's kill all the libMesaGL* stuff from being installed by xorg-x11. The opengl-update ebuild takes care of removing the symlinks it installed.
Done in >=6.8.1.902. That should be it for this.
ls -l /usr/lib/libMesaGLU.so lrwxrwxrwx 1 root root 13 nov 20 01:08 /usr/lib/libMesaGLU.so -> libGLU.so.1.3 qpkg -f /usr/lib/libMesaGLU.so returns nothing. libMesaGL.so was deleted, but not libMesaGLU.so Is it as it should be? it looks wrong to me.
correct, libMesaGLU should go away too.
Reopening till it happens
opengl-update didn't install libMesaGLU, just libMesaGL... That's all on the xorg-x11 ebuild.
Seems fixed
