LGTM, by the way, I just compare to pkgsrc MesaLib as the canonical
version :-)
On Mon, Apr 22, 2019 at 08:48:05AM +0200, Yorick Hardy wrote:
> On 2019-04-18, co...@sdf.org wrote:
> > LD_PRELOAD=/usr/lib/libpthread.so fixes it.
> > It's the libc stubs. I don't know what to link against
On 2019-04-18, co...@sdf.org wrote:
> LD_PRELOAD=/usr/lib/libpthread.so fixes it.
> It's the libc stubs. I don't know what to link against libpthread but
> pkgsrc is cheating by having glmark2 linked with libpthread.
Thank you for updating Mesa, it is much appreciated. SDL2 applications
which
On Thu, Apr 18, 2019 at 11:45:28AM +, co...@sdf.org wrote:
> LD_PRELOAD=/usr/lib/libpthread.so fixes it.
> It's the libc stubs. I don't know what to link against libpthread but
> pkgsrc is cheating by having glmark2 linked with libpthread.
Fixes the abort at the end too, and ties in with the
I checked with pkgsrc xorg, and it aborts with it too.
so it's not my fault here, probably.
LD_PRELOAD=/usr/lib/libpthread.so fixes it.
It's the libc stubs. I don't know what to link against libpthread but
pkgsrc is cheating by having glmark2 linked with libpthread.
On Thu, Apr 18, 2019 at 11:33:09AM +0100, Patrick Welche wrote:
> Add gl, egl and glx loader using GLAD.
>
> Instead of hard linking against libGL, libEGL and libGLESv2 we can
> load the entry points at runtime. Loading dynamically is more
> flexible across different
On Wed, Apr 17, 2019 at 05:43:24PM +0100, Patrick Welche wrote:
> On Tue, Apr 16, 2019 at 09:48:26PM +, co...@sdf.org wrote:
> > > I wonder why you don't see this too...
> >
> > fwiw, I am using pkgsrc glmark2.
>
> Thanks for the hint - I couldn't compile pkgsrc glmark2, which encouraged
>
On Tue, Apr 16, 2019 at 09:48:26PM +, co...@sdf.org wrote:
> > I wonder why you don't see this too...
>
> fwiw, I am using pkgsrc glmark2.
Thanks for the hint - I couldn't compile pkgsrc glmark2, which encouraged
me to update it locally. Turns out the reason I couldn't is that my
x11-links
> I wonder why you don't see this too...
fwiw, I am using pkgsrc glmark2.
On Thu, Apr 11, 2019 at 04:54:03PM +, co...@sdf.org wrote:
> On Thu, Apr 11, 2019 at 04:49:09PM +, co...@sdf.org wrote:
> > argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
> > complicating testing :_/
>
> Ah, disregard, I had the old libGL.so.3.0 (because I
FYI glmark2 ran rather well under VirtualBox a moment ago with a few
hours old system, only crashing on exit:
...
Reading symbols from /usr/pkg/bin/glmark2...done.
[New process 1]
[New process 4]
Core was generated by `glmark2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0
On Thu, Apr 11, 2019 at 04:49:09PM +, co...@sdf.org wrote:
> argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
> complicating testing :_/
Ah, disregard, I had the old libGL.so.3.0 (because I unpacked sets, but
for this manipulation I only re-linked libGL.so.
Putting
argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
complicating testing :_/
On Thu, Apr 11, 2019 at 10:03:24AM +, co...@sdf.org wrote:
> This avoids the crash but it crashes on exit too
I still seem to get the crash on start?
(gdb) bt
#0 0x7f7ff58427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12
#1 0x7f7ff16096ee in pthread_sigmask (how=,
This avoids the crash but it crashes on exit too
Index: Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/libGL/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- Makefile9 Apr 2019 14:31:06 - 1.24
On Thu, Apr 11, 2019 at 10:26:36AM +0100, Patrick Welche wrote:
> I'm trying a slightly newer glmark2 as per trivial patch attached, but
> get the same abort in _sys___sigprocmask14 as you do.
P.S. I also did rm -rf ~/.cache just in case, and that didn't help, an
empty index appeared
$ hexdump
On Tue, Apr 09, 2019 at 04:18:59PM +, co...@sdf.org wrote:
> glmark2 aborts for me, but I don't understand why.
It took a while to rebuild with your changes - thanks for fixing the
dlopen!
I'm trying a slightly newer glmark2 as per trivial patch attached, but
get the same abort in
Just FYI - I am getting the same message whe starting kde4's konqueror:
There was an error loading the module Dolphin View.
The diagnostics is:
Cannot load library /usr/pkg/lib/kde4/dolphinpart.so:
(/usr/X11R7/lib/libGL.so.3: Use of initialized Thread Local Storage
with model initial-exec and
glmark2 aborts for me, but I don't understand why.
> gdb -q (which glmark2)
Reading symbols from /usr/pkg/bin/glmark2...done.
(gdb) r
Starting program: /usr/pkg/bin/glmark2
[New LWP 1 of process 27174]
Thread 2 received signal SIGABRT, Aborted.
0x74c647e427ca in _sys___sigprocmask14 () from
On Tue, Apr 09, 2019 at 01:41:58PM +0200, Joerg Sonnenberger wrote:
> Sorry, my magic 8-ball is broken. dlerror?
coypu@ already did the honours:
/usr/X11R7/lib/libGL.so: Use of initialized Thread Local Storage with model
initial-exec and dlopen is not supported
Cheers,
Patrick
... but maybe we want to define -DPTHREADS?
On Tue, Apr 09, 2019 at 12:17:46PM +0100, Patrick Welche wrote:
> On Tue, Apr 09, 2019 at 10:38:14AM +, co...@sdf.org wrote:
> > thanks to jmcneill for suggesting dlerror();
> >
> > perhaps we need to remove -DGLX_USE_TLS. it otherwise uses TLS via
> > pthread.
> >
> >
On Tue, Apr 09, 2019 at 10:38:14AM +, co...@sdf.org wrote:
> thanks to jmcneill for suggesting dlerror();
>
> perhaps we need to remove -DGLX_USE_TLS. it otherwise uses TLS via
> pthread.
>
> /usr/X11R7/lib/libGL.so: Use of initialized Thread Local Storage with model
> initial-exec and
thanks to jmcneill for suggesting dlerror();
perhaps we need to remove -DGLX_USE_TLS. it otherwise uses TLS via
pthread.
/usr/X11R7/lib/libGL.so: Use of initialized Thread Local Storage with model
initial-exec and dlopen is not supported
I'm going to test
Index: libmesa.mk
On Tue, Apr 09, 2019 at 10:05:08AM +0100, Patrick Welche wrote:
> On Fri, Apr 05, 2019 at 04:10:24PM +, co...@sdf.org 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
On Fri, Apr 05, 2019 at 04:10:24PM +, co...@sdf.org 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
On Sun, Apr 07, 2019 at 02:29:11PM +0900, Rin Okuyama wrote:
> This is because Makefile didn't handle objdir correctly.
> Should be fixed now.
Indeed - thanks for fixing it!
Cheers,
Patrick
> On 2019/04/06 22:42, Patrick Welche wrote:
> > On Sat, Apr 06, 2019 at 05:18:58AM +1100, matthew green
This is because Makefile didn't handle objdir correctly.
Should be fixed now.
Thanks,
rin
On 2019/04/06 22:42, Patrick Welche wrote:
On Sat, Apr 06, 2019 at 05:18:58AM +1100, matthew green wrote:
thanks for the original work and fixing this i386 thing!
If you would like to do an update
I was able to do a full build with a cvs update some 7 hours ago.
Built-in Xorg is fine with AIGLX enabled now.
On Sat, 6 Apr 2019 at 15:31, Patrick Welche wrote:
>
> On Sat, Apr 06, 2019 at 02:42:57PM +0100, Patrick Welche wrote:
> > On Sat, Apr 06, 2019 at 05:18:58AM +1100, matthew green
On Sat, Apr 06, 2019 at 02:42:57PM +0100, Patrick Welche wrote:
> On Sat, Apr 06, 2019 at 05:18:58AM +1100, matthew green wrote:
> > thanks for the original work and fixing this i386 thing!
> >
> > > If you would like to do an update build, you will likely have to remove
> > > many directories in
On Sat, Apr 06, 2019 at 05:18:58AM +1100, matthew green wrote:
> thanks for the original work and fixing this i386 thing!
>
> > 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.
>
> you
thanks for the original work and fixing this i386 thing!
> 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.
you may also have to blow away ./usr/X11R7 in the destdir. i recall
hving a build
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
33 matches
Mail list logo
