Re: Mesa update
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 libpthread but
> > pkgsrc is cheating by having glmark2 linked with libpthread.
>
> Thank you for updating Mesa, it is much appreciated. SDL2 applications
> which load libGL.so seem to fail due to missing symbols, I had to add
> some dependencies as below. Is this correct?
>
> --
> Kind regards,
>
> Yorick Hardy
>
> Index: external/mit/xorg/lib/Makefile
> ===
> RCS file: /cvsroot/src/external/mit/xorg/lib/Makefile,v
> retrieving revision 1.49
> diff -u -u -r1.49 Makefile
> --- external/mit/xorg/lib/Makefile16 Apr 2019 21:20:51 - 1.49
> +++ external/mit/xorg/lib/Makefile22 Apr 2019 06:43:24 -
> @@ -20,10 +20,12 @@
> .endif
> SUBDIR+=libxcb \
> .WAIT
> +SUBDIR+=libX11 \
> + .WAIT
> .if !defined(MLIBDIR)
> SUBDIR+=${EXTRA_DRI_DIRS} dri${OLD_PREFIX} gallium${OLD_PREFIX}
> .endif
> -SUBDIR+=fontconfig libSM libX11 \
> +SUBDIR+=fontconfig libSM \
> .WAIT \
> libXcomposite libXdamage libXext libXfixes libXt \
> libxkbfile libepoxy \
> Index: external/mit/xorg/lib/gallium/Makefile
> ===
> RCS file: /cvsroot/src/external/mit/xorg/lib/gallium/Makefile,v
> retrieving revision 1.25
> diff -u -u -r1.25 Makefile
> --- external/mit/xorg/lib/gallium/Makefile16 Apr 2019 17:29:09 -
> 1.25
> +++ external/mit/xorg/lib/gallium/Makefile22 Apr 2019 06:43:24 -
> @@ -957,6 +957,9 @@
> LIBDPLIBS+= terminfo${.CURDIR}/../../../../../lib/libterminfo
> LIBDPLIBS+= z ${.CURDIR}/../../../../../lib/libz
> LIBDPLIBS+= execinfo${.CURDIR}/../../../../../lib/libexecinfo
> +LIBDPLIBS+= xcb ${.CURDIR}/../libxcb/libxcb
> +LIBDPLIBS+= xcb-dri2${.CURDIR}/../libxcb/dri2
> +LIBDPLIBS+= X11-xcb ${.CURDIR}/../libX11/libX11-xcb
>
> # gallium drivers requiring LLVM
> .if ${BUILD_LLVMPIPE} == 1 || ${BUILD_RADEON} == 1
Re: Mesa update
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 load libGL.so seem to fail due to missing symbols, I had to add
some dependencies as below. Is this correct?
--
Kind regards,
Yorick Hardy
Index: external/mit/xorg/lib/Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/Makefile,v
retrieving revision 1.49
diff -u -u -r1.49 Makefile
--- external/mit/xorg/lib/Makefile 16 Apr 2019 21:20:51 - 1.49
+++ external/mit/xorg/lib/Makefile 22 Apr 2019 06:43:24 -
@@ -20,10 +20,12 @@
.endif
SUBDIR+=libxcb \
.WAIT
+SUBDIR+=libX11 \
+ .WAIT
.if !defined(MLIBDIR)
SUBDIR+=${EXTRA_DRI_DIRS} dri${OLD_PREFIX} gallium${OLD_PREFIX}
.endif
-SUBDIR+=fontconfig libSM libX11 \
+SUBDIR+=fontconfig libSM \
.WAIT \
libXcomposite libXdamage libXext libXfixes libXt \
libxkbfile libepoxy \
Index: external/mit/xorg/lib/gallium/Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/gallium/Makefile,v
retrieving revision 1.25
diff -u -u -r1.25 Makefile
--- external/mit/xorg/lib/gallium/Makefile 16 Apr 2019 17:29:09 -
1.25
+++ external/mit/xorg/lib/gallium/Makefile 22 Apr 2019 06:43:24 -
@@ -957,6 +957,9 @@
LIBDPLIBS+=terminfo${.CURDIR}/../../../../../lib/libterminfo
LIBDPLIBS+=z ${.CURDIR}/../../../../../lib/libz
LIBDPLIBS+=execinfo${.CURDIR}/../../../../../lib/libexecinfo
+LIBDPLIBS+=xcb ${.CURDIR}/../libxcb/libxcb
+LIBDPLIBS+=xcb-dri2${.CURDIR}/../libxcb/dri2
+LIBDPLIBS+=X11-xcb ${.CURDIR}/../libX11/libX11-xcb
# gallium drivers requiring LLVM
.if ${BUILD_LLVMPIPE} == 1 || ${BUILD_RADEON} == 1
Re: Mesa update
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 strange return value from pthread_create! Thanks, Patrick
Re: Mesa update
I checked with pkgsrc xorg, and it aborts with it too. so it's not my fault here, probably.
Re: Mesa update
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.
Re: Mesa update
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 platforms. > > Note that the glad loaders are licensed under public domain. > > Preparation for Windows support in Issue #9. > I know that EGL needs the same treatment, at least...
Re: Mesa update
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 > me to update it locally. Turns out the reason I couldn't is that my > x11-links were old. pkgsrc glmark2 now works for me. > > The new glmark2 still dumps core - it seems that pthread_create() is > returning 1. (More later) glmark2 bisection gives a7bd0084f67b80ae9c32189e4f28a4e7d08f0b92 is the first bad commit commit a7bd0084f67b80ae9c32189e4f28a4e7d08f0b92 Author: Jamie Madill Date: Thu Feb 7 23:33:08 2019 -0500 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 platforms. Note that the glad loaders are licensed under public domain. Preparation for Windows support in Issue #9. e.g. -#include -#include +#include Cheers, Patrick
Re: Mesa update
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 were old. pkgsrc glmark2 now works for me. The new glmark2 still dumps core - it seems that pthread_create() is returning 1. (More later) Cheers, Patrick
Re: Mesa update
> I wonder why you don't see this too... fwiw, I am using pkgsrc glmark2.
Re: Mesa update
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 unpacked sets, but > for this manipulation I only re-linked libGL.so. > > Putting libGL.so that is linked against pthread makes it work as befor.e Double checking, I zapped /usr/obj, made a new release with this morning's source, deleting DESTDIR. With those fresh sets installed, and checking: libGL.so.3.0: -lXext.7 => /usr/X11R7/lib/libXext.so.7 -lX11.7 => /usr/X11R7/lib/libX11.so.7 -lxcb.2 => /usr/X11R7/lib/libxcb.so.2 -lXau.7 => /usr/X11R7/lib/libXau.so.7 -lc.12 => /usr/lib/libc.so.12 -lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7 -lXxf86vm.2 => /usr/X11R7/lib/libXxf86vm.so.2 -lXfixes.4 => /usr/X11R7/lib/libXfixes.so.4 -lXdamage.2 => /usr/X11R7/lib/libXdamage.so.2 -lglapi.1 => /usr/X11R7/lib/libglapi.so.1 -lstdc++.9 => /usr/lib/libstdc++.so.9 -lm.0 => /usr/lib/libm.so.0 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 -ldrm.3 => /usr/X11R7/lib/libdrm.so.3 -lpci.2 => /usr/lib/libpci.so.2 -lX11-xcb.1 => /usr/X11R7/lib/libX11-xcb.so.1 -lxcb-dri2.0 => /usr/X11R7/lib/libxcb-dri2.so.0 -lxcb-glx.0 => /usr/X11R7/lib/libxcb-glx.so.0 -lexpat.2 => /usr/lib/libexpat.so.2 -lpthread.1 => /usr/lib/libpthread.so.1 so there is a pthread, I see: (gdb) run Starting program: /usr/pkg/bin/glmark2 [New LWP 1 of process 792] Thread 2 received signal SIGABRT, Aborted. 0x7f7ff58427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12 (gdb) bt #0 0x7f7ff58427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12 #1 0x7f7ff16096ee in pthread_sigmask (how=, set=, oset=) at /usr/src/lib/libpthread/pthread_misc.c:146 #2 0x7f7ff0828eee in u_thread_create ( routine=0x7f7ff08288fd , param=0x7f7ff7ee4120) at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_thread.h:49 #3 util_queue_init (queue=queue@entry=0x7f7ff7e90900, name=name@entry=0x7f7ff0cdf8ba "disk$", max_jobs=max_jobs@entry=32, num_threads=num_threads@entry=1, flags=flags@entry=7) at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_queue.c:377 #4 0x7f7ff0827c8b in disk_cache_create ( gpu_name=gpu_name@entry=0x7f7fd765 "i965_0126", driver_id=driver_id@entry=0x7f7fd770 "1bddf4975d907e87b5041531bb48868ebeba7ab0", driver_flags=0) at /usr/xsrc/external/mit/MesaLib/dist/src/util/disk_cache.c:387 #5 0x7f7ff0826b1c in brw_disk_cache_init ( screen=screen@entry=0x7f7ff7bd3030) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/i965/brw_disk_cache.c:401 #6 0x7f7ff06e9091 in intelInitScreen2 (dri_screen=) at i965_intel_screen.c:2751 #7 0x7f7ff0b39da7 in driCreateNewScreen2 (scrn=0, fd=4, extensions=, driver_extensions=, driver_configs=0x7f7fe2e8, data=0x7f7ff7e32000) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/common/dri_util.c:153 #8 0x7f7ff4247966 in dri2CreateScreen (screen=0, priv=0x7f7ff7e89150) at /usr/xsrc/external/mit/MesaLib/dist/src/glx/dri2_glx.c:1279 #9 0x7f7ff422e586 in AllocAndFetchScreenConfigs (priv=0x7f7ff7e89150, dpy=0x7f7ff7e72000) at /usr/xsrc/external/mit/MesaLib/dist/src/glx/glxext.c:826 #10 __glXInitialize (dpy=0x7f7ff7e72000) at /usr/xsrc/external/mit/MesaLib/dist/src/glx/glxext.c:949 #11 0x7f7ff423014a in glXQueryVersion (dpy=, major=0x7f7fe3a8, minor=0x7f7fe3ac) at /usr/xsrc/external/mit/MesaLib/dist/src/glx/glxcmds.c:485 #12 0x0040b320 in gladLoadGLXUserPtr () #13 0x00407488 in GLStateGLX::init_display ( this=this@entry=0x7f7fe510, native_display=, visual_config=...) at ../src/gl-state-glx.cpp:44 #14 0x00405593 in CanvasGeneric::init (this=0x7f7fe560) at ../src/canvas-generic.cpp:43 #15 0x004cf119 in main (argc=, argv=) at ../src/main.cpp:205 (at least symbols seem happy...) I wonder why you don't see this too... Cheers, Patrick
Re: Mesa update
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 0x7d94d0bacf78 in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so [Current thread is 1 (process 1)] (gdb) bt #0 0x7d94d0bacf78 in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so #1 0x7d94d0bad251 in ralloc_free () from /usr/X11R7/lib/modules/dri/swrast_dri.so #2 0x7d94d0622a35 in _mesa_glsl_release_builtin_functions() () from /usr/X11R7/lib/modules/dri/swrast_dri.so #3 0x7d94d0d19083 in _mesa_destroy_shader_compiler () from /usr/X11R7/lib/modules/dri/swrast_dri.so #4 0x7d94d045f5e9 in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so #5 0x7d94da849f40 in ?? () #6 0x7d94d2244279 in _fini () from /usr/X11R7/lib/modules/dri/swrast_dri.so #7 0x in ?? () On Thu, 11 Apr 2019 at 17:54, 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 unpacked sets, but > for this manipulation I only re-linked libGL.so. > > Putting libGL.so that is linked against pthread makes it work as befor.e --
Re: Mesa update
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 libGL.so that is linked against pthread makes it work as befor.e
Re: Mesa update
argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH complicating testing :_/
Re: Mesa update
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=, set=, oset=) at /usr/src/lib/libpthread/pthread_misc.c:146 #2 0x7f7ff0828eee in u_thread_create ( routine=0x7f7ff08288fd , param=0x7f7ff7ee4120) at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_thread.h:49 #3 util_queue_init (queue=queue@entry=0x7f7ff7e90900, name=name@entry=0x7f7ff0cdf8ba "disk$", max_jobs=max_jobs@entry=32, num_threads=num_threads@entry=1, flags=flags@entry=7) at /usr/xsrc/external/mit/MesaLib/dist/src/util/u_queue.c:377 #4 0x7f7ff0827c8b in disk_cache_create ( gpu_name=gpu_name@entry=0x7f7fd795 "i965_0126", driver_id=driver_id@entry=0x7f7fd7a0 "1bddf4975d907e87b5041531bb48868ebeba7ab0", driver_flags=0) at /usr/xsrc/external/mit/MesaLib/dist/src/util/disk_cache.c:387 #5 0x7f7ff0826b1c in brw_disk_cache_init ( screen=screen@entry=0x7f7ff7bd3030) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/i965/brw_disk_cache.c:401 #6 0x7f7ff06e9091 in intelInitScreen2 (dri_screen=) at i965_intel_screen.c:2751 #7 0x7f7ff0b39da7 in driCreateNewScreen2 (scrn=0, fd=4, extensions=, driver_extensions=, driver_configs=0x7f7fe318, data=0x7f7ff7e32000) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/common/dri_util.c:153 ... lib/libpthread features now... Cheers, Patrick
Re: Mesa update
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
+++ Makefile11 Apr 2019 10:00:04 -
@@ -191,7 +191,8 @@
xcb-dri2${.CURDIR}/../libxcb/dri2 \
xcb-glx ${.CURDIR}/../libxcb/glx \
expat ${NETBSDSRCDIR}/external/mit/expat/lib/libexpat
\
- m ${NETBSDSRCDIR}/lib/libm
+ m ${NETBSDSRCDIR}/lib/libm \
+ pthread ${NETBSDSRCDIR}/lib/libpthread
MKLINT=no
Re: Mesa update
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 -C .cache/mesa_shader_cache/index 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0014 00 00 00 00 00 00 00 00 || 00140008 $ Not sure if relevant... P
Re: Mesa update
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 _sys___sigprocmask14 as you do.
Now to go off on a tangent:
(gdb) symbol-file /usr/libdata/debug/usr/X11R7/lib/libGL.so.3.0.debug
Load new symbol table from
"/usr/libdata/debug/usr/X11R7/lib/libGL.so.3.0.debug"? (y or n) y
Reading symbols from /usr/libdata/debug/usr/X11R7/lib/libGL.so.3.0.debug...(no
debugging symbols found)...done.
(gdb) symbol-file
/usr/libdata/debug/usr/X11R7/lib/modules/dri/i965_dri.so.0.debug
Reading symbols from
/usr/libdata/debug/usr/X11R7/lib/modules/dri/i965_dri.so.0.debug...(no
debugging symbols found)...done.
(gdb) symbol-file /usr/libdata/debug/lib/libc.so.12.212.debug
Reading symbols from /usr/libdata/debug/lib/libc.so.12.212.debug...(no
debugging symbols found)...done.
"no debugging symbols found"?
(slighlty different to
http://mail-index.netbsd.org/netbsd-users/2019/04/09/msg022483.html
)
> > 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 /usr/lib/libc.so.12
...
> #5 0x74c6434e9091 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so
> #6 0x74c643939da7 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so
also i965 here so we have similar hardware...
Cheers,
Patrick
? glmark2.diff
Index: Makefile
===
RCS file: /cvsroot/pkgsrc/benchmarks/glmark2/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- Makefile3 Jul 2018 05:03:03 - 1.12
+++ Makefile11 Apr 2019 09:15:22 -
@@ -1,9 +1,10 @@
# $NetBSD: Makefile,v 1.12 2018/07/03 05:03:03 adam Exp $
DISTNAME= glmark2-2017.07
+PKGREVISION= 1
CATEGORIES=benchmarks
MASTER_SITES= ${MASTER_SITE_GITHUB:=glmark2/}
-GITHUB_TAG=168d2f1650c84be3f13d1a5b76ccec8cbb89188e
+GITHUB_TAG=eaa7062f63da853f8ed9c94442b7a32d3335
MAINTAINER=pr...@cam.ac.uk
HOMEPAGE= https://github.com/glmark2/glmark2
@@ -12,8 +13,6 @@
USE_LANGUAGES= c c++11
-PYTHON_VERSIONS_INCOMPATIBLE= 34 35 36 37
-
USE_TOOLS+=pkg-config
.include "../../mk/dlopen.buildlink3.mk"
@@ -35,7 +34,8 @@
do-build:
cd ${WRKSRC:Q} && \
- ${SETENV} ${CONFIGURE_ENV} ${PYTHONBIN} ./waf build
+ ${SETENV} ${CONFIGURE_ENV} ${PYTHONBIN} ./waf build \
+ -j ${MAKE_JOBS}
do-install:
cd ${WRKSRC:Q} && \
Index: distinfo
===
RCS file: /cvsroot/pkgsrc/benchmarks/glmark2/distinfo,v
retrieving revision 1.6
diff -u -r1.6 distinfo
--- distinfo2 Jun 2018 13:16:42 - 1.6
+++ distinfo11 Apr 2019 09:15:22 -
@@ -1,6 +1,6 @@
$NetBSD: distinfo,v 1.6 2018/06/02 13:16:42 prlw1 Exp $
-SHA1 (glmark2-2017.07-168d2f1650c84be3f13d1a5b76ccec8cbb89188e.tar.gz) =
5a27940b9e4ae2a1bc025079802e116af127479a
-RMD160 (glmark2-2017.07-168d2f1650c84be3f13d1a5b76ccec8cbb89188e.tar.gz) =
60572134a88fb3fd1a95f3be35d26b6c4edd852b
-SHA512 (glmark2-2017.07-168d2f1650c84be3f13d1a5b76ccec8cbb89188e.tar.gz) =
9e2c8a2e2da5514476c3fe09e5d87380654b052b8488cfff2d7b06127bfcb92ca81eac09aea34d194ac4e0b9a0758696cc0ac0d4bc1117be5ed858a0ee22a3cc
-Size (glmark2-2017.07-168d2f1650c84be3f13d1a5b76ccec8cbb89188e.tar.gz) =
7827207 bytes
+SHA1 (glmark2-2017.07-eaa7062f63da853f8ed9c94442b7a32d3335.tar.gz) =
8fa39ccafa32ffb0878faa6281730446e1b983aa
+RMD160 (glmark2-2017.07-eaa7062f63da853f8ed9c94442b7a32d3335.tar.gz) =
a18003b4719b8fd55d7ad2bc484eb9d2ba24e707
+SHA512 (glmark2-2017.07-eaa7062f63da853f8ed9c94442b7a32d3335.tar.gz) =
e8356144bfe892469c489c9c57fabc4b7ec068043ba018b73cb11be979e23209ea3715e5e49e60d091609f4e6e344e9985565f7f256ab129d618722d000a022f
+Size (glmark2-2017.07-eaa7062f63da853f8ed9c94442b7a32d3335.tar.gz) =
8556288 bytes
Re: Mesa update
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 dlopen is not supported) ... On Tue, 9 Apr 2019 at 17:19, wrote: > > 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 /usr/lib/libc.so.12 > (gdb) info registers > rax0x0 0 > rbx0x74c64a457900 128394998413568 > rcx0x74c647e427ca 128394958481354 > rdx0x0 0 > rsi0x7f7fff33f090 140187719168144 > rdi0x3 3 > rbp0x74c64a4ac0e0 0x74c64a4ac0e0 > rsp0x7f7fff33f038 0x7f7fff33f038 > r8 0x74c64a4adb38 128394998766392 > r9 0x74c644400900 128394897393920 > r100x0 0 > r110x202514 > r120x0 0 > r130x74c64a4ab120 128394998755616 > r140x0 0 > r150x -1 > rip0x74c647e427ca 0x74c647e427ca <_sys___sigprocmask14+10> > eflags 0x202[ IF ] > cs 0x47 71 > ss 0x3f 63 > ds 0x23 35 > es 0x23 35 > fs 0x0 0 > gs 0x0 0 > (gdb) bt > #0 0x74c647e427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12 > #1 0x74c642e096ee in pthread_sigmask () from /usr/lib/libpthread.so.1 > #2 0x74c643628eee in util_queue_init () from > /usr/X11R7/lib/modules/dri/i965_dri.so > #3 0x74c643627c8b in disk_cache_create () from > /usr/X11R7/lib/modules/dri/i965_dri.so > #4 0x74c643626b1c in brw_disk_cache_init () from > /usr/X11R7/lib/modules/dri/i965_dri.so > #5 0x74c6434e9091 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so > #6 0x74c643939da7 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so > #7 0x74c649247956 in ?? () from /usr/X11R7/lib/libGL.so.3 > #8 0x74c64922e576 in __glXInitialize () from /usr/X11R7/lib/libGL.so.3 > #9 0x74c64923013a in glXQueryVersion () from /usr/X11R7/lib/libGL.so.3 > #10 0x00408cdd in GLStateGLX::check_glx_version > (this=this@entry=0x7f7fff340100) at ../src/gl-state-glx.cpp:160 > #11 0x0040904f in GLStateGLX::ensure_glx_fbconfig > (this=this@entry=0x7f7fff340100) at ../src/gl-state-glx.cpp:241 > #12 0x00409329 in GLStateGLX::gotNativeConfig (this=0x7f7fff340100, > vid=@0x7f7fff33ff5c: 0) at ../src/gl-state-glx.cpp:128 > #13 0x00407268 in CanvasGeneric::resize_no_viewport > (this=this@entry=0x7f7fff340150, width=800, height=600) at > ../src/canvas-generic.cpp:225 > #14 0x00408739 in CanvasGeneric::reset (this=0x7f7fff340150) at > ../src/canvas-generic.cpp:56 > #15 0x004cdfa3 in main (argc=, argv=) > at ../src/main.cpp:198 > (gdb) disas > Dump of assembler code for function _sys___sigprocmask14: >0x74c647e427c0 <+0>: mov$0x125,%eax >0x74c647e427c5 <+5>: mov%rcx,%r10 >0x74c647e427c8 <+8>: syscall > => 0x74c647e427ca <+10>:jb 0x74c647e427cd > <_sys___sigprocmask14+13> >0x74c647e427cc <+12>:retq >0x74c647e427cd <+13>:jmpq 0x74c647f999e0 <__cerror> > End of assembler dump. > --
Re: Mesa update
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 /usr/lib/libc.so.12 (gdb) info registers rax0x0 0 rbx0x74c64a457900 128394998413568 rcx0x74c647e427ca 128394958481354 rdx0x0 0 rsi0x7f7fff33f090 140187719168144 rdi0x3 3 rbp0x74c64a4ac0e0 0x74c64a4ac0e0 rsp0x7f7fff33f038 0x7f7fff33f038 r8 0x74c64a4adb38 128394998766392 r9 0x74c644400900 128394897393920 r100x0 0 r110x202514 r120x0 0 r130x74c64a4ab120 128394998755616 r140x0 0 r150x -1 rip0x74c647e427ca 0x74c647e427ca <_sys___sigprocmask14+10> eflags 0x202[ IF ] cs 0x47 71 ss 0x3f 63 ds 0x23 35 es 0x23 35 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x74c647e427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12 #1 0x74c642e096ee in pthread_sigmask () from /usr/lib/libpthread.so.1 #2 0x74c643628eee in util_queue_init () from /usr/X11R7/lib/modules/dri/i965_dri.so #3 0x74c643627c8b in disk_cache_create () from /usr/X11R7/lib/modules/dri/i965_dri.so #4 0x74c643626b1c in brw_disk_cache_init () from /usr/X11R7/lib/modules/dri/i965_dri.so #5 0x74c6434e9091 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so #6 0x74c643939da7 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so #7 0x74c649247956 in ?? () from /usr/X11R7/lib/libGL.so.3 #8 0x74c64922e576 in __glXInitialize () from /usr/X11R7/lib/libGL.so.3 #9 0x74c64923013a in glXQueryVersion () from /usr/X11R7/lib/libGL.so.3 #10 0x00408cdd in GLStateGLX::check_glx_version (this=this@entry=0x7f7fff340100) at ../src/gl-state-glx.cpp:160 #11 0x0040904f in GLStateGLX::ensure_glx_fbconfig (this=this@entry=0x7f7fff340100) at ../src/gl-state-glx.cpp:241 #12 0x00409329 in GLStateGLX::gotNativeConfig (this=0x7f7fff340100, vid=@0x7f7fff33ff5c: 0) at ../src/gl-state-glx.cpp:128 #13 0x00407268 in CanvasGeneric::resize_no_viewport (this=this@entry=0x7f7fff340150, width=800, height=600) at ../src/canvas-generic.cpp:225 #14 0x00408739 in CanvasGeneric::reset (this=0x7f7fff340150) at ../src/canvas-generic.cpp:56 #15 0x004cdfa3 in main (argc=, argv=) at ../src/main.cpp:198 (gdb) disas Dump of assembler code for function _sys___sigprocmask14: 0x74c647e427c0 <+0>: mov$0x125,%eax 0x74c647e427c5 <+5>: mov%rcx,%r10 0x74c647e427c8 <+8>: syscall => 0x74c647e427ca <+10>:jb 0x74c647e427cd <_sys___sigprocmask14+13> 0x74c647e427cc <+12>:retq 0x74c647e427cd <+13>:jmpq 0x74c647f999e0 <__cerror> End of assembler dump.
Re: Mesa update
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
Re: Mesa update
... but maybe we want to define -DPTHREADS?
Re: Mesa update
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. > > > > /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 > > Thanks! > > (This might end up being "interesting": > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson.build#L346 > > so AFAICT the "default" meson build defines GLX_USE_TLS no matter what...) > > > Cheers, > > Patrick There's a bunch of patches in the pkgsrc mesalib18, I'll give them a try. patch-src_glx_glxclient.h patch-src_glx_glxcurrent.c patch-src_mapi_entry__x86-64__tls.h patch-src_mapi_entry__x86__tls.h patch-src_mapi_u__current.c patch-src_mapi_u__current.h (they apply with some fuzz)
Re: Mesa update
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 dlopen is not supported > > I'm going to test Thanks! (This might end up being "interesting": https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson.build#L346 so AFAICT the "default" meson build defines GLX_USE_TLS no matter what...) Cheers, Patrick
Re: Mesa update
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 === RCS file: /cvsroot/src/external/mit/xorg/lib/libmesa.mk,v retrieving revision 1.6 diff -u -r1.6 libmesa.mk --- libmesa.mk 3 Apr 2019 15:26:34 - 1.6 +++ libmesa.mk 9 Apr 2019 10:37:54 - @@ -521,7 +521,6 @@ -DHAVE_LIBDRM -DGLX_USE_DRM \ -DGLX_INDIRECT_RENDERING \ -DGLX_DIRECT_RENDERING \ - -DGLX_USE_TLS \ -DHAVE_X11_PLATFORM \ -DHAVE_DRM_PLATFORM \ -DENABLE_SHADER_CACHE \ Index: libGL/Makefile === RCS file: /cvsroot/src/external/mit/xorg/lib/libGL/Makefile,v retrieving revision 1.23 diff -u -r1.23 Makefile --- libGL/Makefile 10 Mar 2019 10:51:58 - 1.23 +++ libGL/Makefile 9 Apr 2019 10:37:55 - @@ -164,7 +164,7 @@ -DHAVE_FUNC_ATTRIBUTE_NORETURN=1 -DHAVE_ENDIAN_H=1 -DHAVE_DLADDR=1 \ -DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 \ -DHAVE_PTHREAD=1 -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 \ - -DHAVE_TIMESPEC_GET -DGLX_USE_TLS + -DHAVE_TIMESPEC_GET .include "../asm.mk" Index: libglapi/Makefile === RCS file: /cvsroot/src/external/mit/xorg/lib/libglapi/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- libglapi/Makefile 10 Mar 2019 10:51:58 - 1.4 +++ libglapi/Makefile 9 Apr 2019 10:37:55 - @@ -68,7 +68,6 @@ -DGLX_USE_DRM \ -DGLX_INDIRECT_RENDERING \ -DGLX_DIRECT_RENDERING \ - -DGLX_USE_TLS \ -DHAVE_X11_PLATFORM \ -DHAVE_DRM_PLATFORM \ -DENABLE_SHADER_CACHE \
Re: Mesa update
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 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
> #include
>
> 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)
Re: Mesa update
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 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
#include
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?!
Cheers,
Patrick
Re: Mesa update
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 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 may also have to blow away ./usr/X11R7 in the destdir. i recall > > > hving a build problem related to headers not being updated. > > > > I blew away /usr/obj completely, and just tried, on amd64, a > > > >sh build.sh -j32 -x -r release > > > > so DESTDIR would have been empty too, and get (twice): > > > > --- dependall --- > > nbmake[7]: nbmake[7]: don't know how to make > > /usr/src/external/bsd/llvm/librt/li > > bLLVMTransformsCoroutines/libLLVMTransformsCoroutines_pic.a. Stop > > nbmake[7]: stopped in /usr/src/external/mit/xorg/lib/gallium > > > > > > Cheers, > > > > Patrick > >
Re: Mesa update
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 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 problem related to headers not being updated. I blew away /usr/obj completely, and just tried, on amd64, a sh build.sh -j32 -x -r release so DESTDIR would have been empty too, and get (twice): --- dependall --- nbmake[7]: nbmake[7]: don't know how to make /usr/src/external/bsd/llvm/librt/li bLLVMTransformsCoroutines/libLLVMTransformsCoroutines_pic.a. Stop nbmake[7]: stopped in /usr/src/external/mit/xorg/lib/gallium Cheers, Patrick
Re: Mesa 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 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 may also have to blow away ./usr/X11R7 in the destdir. i recall > > > hving a build problem related to headers not being updated. > > > > I blew away /usr/obj completely, and just tried, on amd64, a > > > > sh build.sh -j32 -x -r release > > > > so DESTDIR would have been empty too, and get (twice): > > > > --- dependall --- > > nbmake[7]: nbmake[7]: don't know how to make > > /usr/src/external/bsd/llvm/librt/li > > bLLVMTransformsCoroutines/libLLVMTransformsCoroutines_pic.a. Stop > > nbmake[7]: stopped in /usr/src/external/mit/xorg/lib/gallium > > (Just tried to avoid the issue by setting MKLINKLIB=no and got > > # build libc/libc.so.12.212 > rm -f libc.so.12.212 > /usr/src/obj.amd64/tooldir.NetBSD-8.99.37-amd64/bin/x86_64--netbsd-gcc > -nodefaul > tlibs -shared -Wl,-soname,libc.so.12 -Wl,--warn-shared-textrel > -Wl,-Map=libc.so > .12.map -Wl,-z,initfirst --sysroot=/store/export/amd64 > -Wl,--warn-shared-textr > el -Wl,-z,relro -o libc.so.12.212.tmp -Wl,-rpath,/lib -L=/lib -Wl,-x > -Wl,--w > hole-archive libc_pic.a -Wl,--no-whole-archive -lgcc > /usr/obj/.amd64/tooldir.NetBSD-8.99.37-amd64/bin/../lib/gcc/x86_64--netbsd/7.4.0 > /../../../../x86_64--netbsd/bin/ld: cannot find -lgcc > collect2: error: ld returned 1 exit status > *** [libc.so.12.212] Error code 1 > ) > > > P --
Re: Mesa update
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 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 problem related to headers not being updated. > > I blew away /usr/obj completely, and just tried, on amd64, a > > sh build.sh -j32 -x -r release > > so DESTDIR would have been empty too, and get (twice): > > --- dependall --- > > nbmake[7]: nbmake[7]: don't know how to make > /usr/src/external/bsd/llvm/librt/li > bLLVMTransformsCoroutines/libLLVMTransformsCoroutines_pic.a. Stop > > nbmake[7]: stopped in /usr/src/external/mit/xorg/lib/gallium > (Just tried to avoid the issue by setting MKLINKLIB=no and got # build libc/libc.so.12.212 rm -f libc.so.12.212 /usr/src/obj.amd64/tooldir.NetBSD-8.99.37-amd64/bin/x86_64--netbsd-gcc -nodefaul tlibs -shared -Wl,-soname,libc.so.12 -Wl,--warn-shared-textrel -Wl,-Map=libc.so .12.map -Wl,-z,initfirst --sysroot=/store/export/amd64 -Wl,--warn-shared-textr el -Wl,-z,relro -o libc.so.12.212.tmp -Wl,-rpath,/lib -L=/lib -Wl,-x -Wl,--w hole-archive libc_pic.a -Wl,--no-whole-archive -lgcc /usr/obj/.amd64/tooldir.NetBSD-8.99.37-amd64/bin/../lib/gcc/x86_64--netbsd/7.4.0 /../../../../x86_64--netbsd/bin/ld: cannot find -lgcc collect2: error: ld returned 1 exit status *** [libc.so.12.212] Error code 1 ) P
Re: Mesa update
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 may also have to blow away ./usr/X11R7 in the destdir. i recall > hving a build problem related to headers not being updated. I blew away /usr/obj completely, and just tried, on amd64, a sh build.sh -j32 -x -r release so DESTDIR would have been empty too, and get (twice): --- dependall --- nbmake[7]: nbmake[7]: don't know how to make /usr/src/external/bsd/llvm/librt/li bLLVMTransformsCoroutines/libLLVMTransformsCoroutines_pic.a. Stop nbmake[7]: stopped in /usr/src/external/mit/xorg/lib/gallium Cheers, Patrick
re: Mesa update
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 problem related to headers not being updated. .mrg.
