pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/graphics



Blair Sadewitz writes:

> Module Name:  pkgsrc
> Committed By: bjs
> Date:         Sun Jul 27 00:03:42 UTC 2008
> 
> Modified Files:
>       pkgsrc/graphics/Mesa: Makefile.common Makefile.lib
>       pkgsrc/graphics/MesaDemos: Makefile PLIST distinfo
>       pkgsrc/graphics/MesaLib: Makefile PLIST distinfo hacks.mk options.mk
>       pkgsrc/graphics/MesaLib/files/configs: default pkgsrc
>       pkgsrc/graphics/MesaLib/patches: patch-ab
>       pkgsrc/graphics/glu: Makefile
>       pkgsrc/graphics/glx-utils: Makefile distinfo
> Added Files:
>       pkgsrc/graphics/MesaLib/patches: patch-ax patch-ay
> Removed Files:
>       pkgsrc/graphics/MesaDemos/patches: patch-aa patch-ab patch-ac patch-af
>           patch-ah patch-ai
>       pkgsrc/graphics/MesaLib/patches: patch-aa patch-af patch-ak patch-al
>           patch-an patch-ao patch-ap
> 
> Log Message:
> Update to Mesa-7.0.4 (the head of the 7.0 branch in GIT).  Basically,
> 
>  - glxinfo/glxgears do not seem to need to be linked to libpthread, and this
>    seems to cause problems on NetBSD with the new drm code.  If I am wrong
>    about this, please let me know.  The only program that seems to need
>    libpthread is glthreads in MesaDemos.

This is almost certainly a workaround for Linux.  I haven't tried
7.0.4 yet, but essentially everything that links to libGL under Linux
has to be linked explicitly with libpthread.so or it will fail to
build.

Under "normal" Linux, libGL.so is linked with libpthread.so.  Under
Pkgsrc we go to inhuman pains to avoid that (at least under
NetBSD-[12].*), which means non-threaded applications under Pkgsrc
fail to build unless they themselves link with libpthread.so.  The
problem never occurs under NetBSD because our libc has threading
stubs.

I use this patch on Linux and NetBSD systems and it works well, but it
does lead to linking in libpthread.so under NetBSD too.  I don't think
that's so unreasonable, but we could reasonably have a special case
for "modern NetBSD" too, and link in libpthread.so for everyone else
(I.e. make the safer assumption that they DON'T have threading stubs).

See also PR#36207, and it also allows mission critical software like
"bzflag" to build under Linux.

--- graphics/MesaLib/Makefile.orig      2007-11-04 11:36:06.000000000 +1300
+++ graphics/MesaLib/Makefile   2008-04-22 02:21:35.000000000 +1200
@@ -54,11 +54,11 @@
 
 .if !empty(MACHINE_PLATFORM:MNetBSD-[12].*)
 .  include "../../devel/pthread-stublib/buildlink3.mk"
-PTHREAD_STUBLIB= "-L${PREFIX}/lib -Wl,-R${PREFIX}/lib -lpthstub"
+PTHREAD_STUBLIB= -L${PREFIX}/lib -Wl,-R${PREFIX}/lib -lpthstub
 .else
-PTHREAD_STUBLIB= # provided by libc
+PTHREAD_STUBLIB= ${PTHREAD_LDFLAGS} ${PTHREAD_LIBS}
 .endif
-PKGSRC_MAKE_ENV+=      PTHREAD_STUBLIB=${PTHREAD_STUBLIB}
+PKGSRC_MAKE_ENV+=      PTHREAD_STUBLIB=${PTHREAD_STUBLIB:Q}
 
 .if !empty(USE_CROSS_COMPILE:M[yY][eE][sS])
 MAKE_ENV+=     CROSS_COMPILING=yes
--- graphics/MesaLib/files/configs/pkgsrc-dri.orig      2008-04-24 19:40:24.0000
00000 +1200
+++ graphics/MesaLib/files/configs/pkgsrc-dri   2008-05-01 16:40:05.000000000 +1
200
@@ -28,7 +28,7 @@
 DRI_LIB_DEPS?= -lm -lexpat $(LIBDRM_LIB)
 GL_LIB_DEPS=\
        -lX11 -lXext -lXxf86vm -lXdamage \
-       -lXfixes -lm $(LIBDRM_LIB) \
+       -lXfixes -lm $(LIBDRM_LIB) $(PTHREAD_STUBLIB) \
        $(XCB_GL_LIB_DEPS)
 
 SRC_DIRS=      glx/x11 mesa glw


Home | Main Index | Thread Index | Old Index