Hi,
On Sun, Aug 20, 2006 at 01:42:23AM +0200, Cyril Brulebois wrote:
> here is a small but important update of the patch. The additional part
> is located in ``additional-GL-mklib.diff'' while the updated patch is
> the ``hurd-dri-drm-updated.diff'' file.
>
> There was an extra mklib for the GL library, which made the package
> useless. With that updated patch, it was possible to build these
> packages:
> - freeglut
> - mesa-utils
> - glitz
>
> BTW, glxgears is running. That seems to be confirming that the package
> is usable like that.
Thank you for all the hard work, Cyril.
> If you'd like to have a look at the list of the files for i386 and
> hurd-i386 packages, I'm including them. The best way to compare them is
> IMHO ``sdiff''.
It seems the remaining file differences are:
* /usr/lib/libGL.so.6.4.2 and symlinks missing in
libgl1-mesa-directfb{,-dev}.
* /usr/lib/dri/*.so missing in libgl1-mesa-dri.
* /usr/lib/libOSMesa.so.6.4.060402 and symlinks additionally in
libgl1-mesa-glx/libgl1-mesa-dev.
The first one is a logical consequence of the lack of directfb support
in the Hurd, though it would be nicer if the libgl1-mesa-directfb*
packages just would not get built at all.
The second one is the main reason for the bug report. I think it is
alright to have a mostly empty libgl1-mesa-dri package as this package
does not seem to have any serious reverse depends outside of x.org.
Again, just not building it would probably also be a solution.
The cause for the additional libOSMesa in libgl1-mesa-glx and -dev is
not really clear to me. This libOSMesa is not exactly identical to the
one in libgl1-mesa-swx11, the symbols are the same, but objdump output
is different for non-weak symbols:
-00000000 DF *UND* 0000002b _mesa_calloc
-00000000 DF *UND* 00000038 _mesa_destroy_framebuffer
+00000000 D *UND* 00000000 _mesa_calloc
+00000000 D *UND* 00000000 _mesa_destroy_framebuffer
Any help on how to get rid of that library in libgl1-mesa-glx is
welcome.
> --- src/mesa/Makefile.old 2006-08-16 10:04:41.000000000 +0000
> +++ src/mesa/Makefile 2006-08-16 10:04:11.000000000 +0000
> @@ -150,10 +150,12 @@
>
> # Make the GL library
> $(LIB_DIR)/$(GL_LIB_NAME): $(STAND_ALONE_OBJECTS)
> +ifndef NO_DRI_NO_DRM
> @ $(TOP)/bin/mklib -o $(GL_LIB) -linker '$(CC)' \
> -major $(GL_MAJOR) -minor $(GL_MINOR) -patch $(GL_TINY) \
> -install $(LIB_DIR) \
> $(MKLIB_OPTIONS) $(GL_LIB_DEPS) $(STAND_ALONE_OBJECTS)
> +endif
>
> # Make the OSMesa library
> $(LIB_DIR)/$(OSMESA_LIB_NAME): $(OSMESA_DRIVER_OBJECTS) $(OSMESA16_OBJECTS)
> --- mesa-6.4.2.old/src/glx/x11/Makefile 2006-08-12 16:59:25.000000000
> +0000
> +++ mesa-6.4.2/src/glx/x11/Makefile 2006-08-12 17:00:02.000000000 +0000
> @@ -33,7 +33,11 @@
> glx_query.c \
> glx_texture_compression.c \
> dri_glx.c \
> - XF86dri.c \
> +
> +ifndef NO_DRI_NO_DRM
> +C_SOURCES += \
> + XF86dri.c
> +endif
>
> X86_SOURCES = $(TOP)/src/mesa/x86/glapi_x86.S
> X86-64_SOURCES = $(TOP)/src/mesa/x86-64/glapi_x86-64.S
> diff -urN mesa-6.4.2.old/src/Mesa/Makefile mesa-6.4.2/src/Mesa/Makefile
> --- mesa-6.4.2.old/src/mesa/Makefile 2006-08-16 10:04:41.000000000 +0000
> +++ mesa-6.4.2/src/mesa/Makefile 2006-08-16 10:04:11.000000000 +0000
> @@ -150,10 +150,12 @@
>
> # Make the GL library
> $(LIB_DIR)/$(GL_LIB_NAME): $(STAND_ALONE_OBJECTS)
> +ifndef NO_DRI_NO_DRM
> @ $(TOP)/bin/mklib -o $(GL_LIB) -linker '$(CC)' \
> -major $(GL_MAJOR) -minor $(GL_MINOR) -patch $(GL_TINY) \
> -install $(LIB_DIR) \
> $(MKLIB_OPTIONS) $(GL_LIB_DEPS) $(STAND_ALONE_OBJECTS)
> +endif
>
> # Make the OSMesa library
> $(LIB_DIR)/$(OSMESA_LIB_NAME): $(OSMESA_DRIVER_OBJECTS) $(OSMESA16_OBJECTS)
This is the upstream part of the patch, which looks good to me. Michel,
do you think this is reasonable to submit upstream?
The Debian part of the patch is now quite unintrusive in my opinion, and
hopefully fine for Marcelo.
In summary, I believe the extra libOSMesa library in libgl1-mesa-glx is
the only minor outstanding issue; and given the importance of mesa as a
Build-Dep (tiff, gtk and Qt need it, and thus a very large chunk of the
archive) I think it is OK to apply this patch for now, unless serious
objections arise.
thanks,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
