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
32 matches
Mail list logo
