Re: Mesa update

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Tue, Apr 09, 2019 at 10:05:08AM +0100, Patrick Welche wrote:
> On Fri, Apr 05, 2019 at 04:10:24PM +0000, coypu%sdf.org@localhost wrote:
> > hi current-users,
> > 
> > -current is now going to use mesa 18.3.4, and on x86, LLVM for radeon
> > and software acceleration. It's faster and supports more modern OpenGL
> > functionality. Software raster on x86 is now done using the faster
> > llvmpipe.
> > (Thanks to mrg@ and joerg@).
> > 
> > This will increase your build times dramatically if you build Xorg on
> > x86, from building LLVM libraries.
> > 
> > If you would like to do an update build, you will likely have to remove
> > many directories in OBJDIR/external/mit/xorg/lib/*.
> > I didn't test this, sorry.
> > 
> > Let me know if there are any situations for which this fails to work. We
> > got really good testing of things before committing it so I don't expect
> > much trouble.
> 
> Wondering why I couldn't get glmark2 to work, I see the following oddity:
> 
> 
> #include <dlfcn.h>
> #include <stdio.h>
> 
> int main()
> {
> 	void *handle;
> 
> 	handle = dlopen("/usr/X11R7/lib/libGL.so.2", RTLD_NOW | RTLD_NODELETE);
> 	printf("GL version 2 handle = %p\n", handle);
> 
> 	handle = dlopen("/usr/X11R7/lib/libGL.so.3", RTLD_NOW | RTLD_NODELETE);
> 	printf("GL version 3 handle = %p\n", handle);
> 
> 	return 0;
> }
> 
> $ ./glmark
> GL version 2 handle = 0x7f7ff7ef9800
> GL version 3 handle = 0x0
> $ file /usr/X11R7/lib/libGL.so.*
> /usr/X11R7/lib/libGL.so.2:   symbolic link to libGL.so.2.0
> /usr/X11R7/lib/libGL.so.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for NetBSD 8.99.3, not stripped
> /usr/X11R7/lib/libGL.so.3:   symbolic link to libGL.so.3.0
> /usr/X11R7/lib/libGL.so.3.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for NetBSD 8.99.37, not stripped
> 
> so why will the old library dlopen, but not the new one?!

(if you try so.3 first, then so.2, you 0x0 and a seg fault - I know you
wouldn't want to load 2 libraries with the same symbols in - but this
illustrates that there is a problem)