Bug 5016 - xorg-server-0.99.3 includes wrong version of xf86drm.c
Summary: xorg-server-0.99.3 includes wrong version of xf86drm.c
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 6.99.99.902 (7.0 RC2)
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Adam Jackson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1690
  Show dependency treegraph
 
Reported: 2005-11-11 12:52 UTC by Felix Kühling
Modified: 2005-11-30 18:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Felix Kühling 2005-11-11 12:52:13 UTC
I configured xorg-server with --prefix=/home/fkuehlin/xorg7rc2 
--localstatedir=/var --enable-static=no --disable-debug --enable-dri
--with-mesa-source=`pwd`/../Mesa-* --disable-dmx --disable-xnest --disable-xvfb
--disable-xorgcfg

The build with gcc 3.3.3 failed with:

xf86drm.c: At top level:
xf86drm.c:1509: error: conflicting types for `drmAgpAlloc'
/home/fkuehlin/xorg7rc2/include/xf86drm.h:580: error: previous declaration of
`drmAgpAlloc'
xf86drm.c:1536: error: conflicting types for `drmAgpFree'
/home/fkuehlin/xorg7rc2/include/xf86drm.h:581: error: previous declaration of
`drmAgpFree'
xf86drm.c:1560: error: conflicting types for `drmAgpBind'
/home/fkuehlin/xorg7rc2/include/xf86drm.h:583: error: previous declaration of
`drmAgpBind'
xf86drm.c:1583: error: conflicting types for `drmAgpUnbind'
/home/fkuehlin/xorg7rc2/include/xf86drm.h:584: error: previous declaration of
`drmAgpUnbind'
xf86drm.c:1773: error: conflicting types for `drmScatterGatherAlloc'
/home/fkuehlin/xorg7rc2/include/xf86drm.h:599: error: previous declaration of
`drmScatterGatherAlloc'
xf86drm.c:1785: error: conflicting types for `drmScatterGatherFree'
/home/fkuehlin/xorg7rc2/include/xf86drm.h:600: error: previous declaration of
`drmScatterGatherFree'
make[5]: *** [libdrm_la-xf86drm.lo] Fehler 1
make[5]: Verlasse Verzeichnis
»/home/fkuehlin/src/xorg7rc2/xorg-server-0.99.3/hw/xfree86/os-support/drm«
make[4]: *** [all-recursive] Fehler 1
make[4]: Verlasse Verzeichnis
»/home/fkuehlin/src/xorg7rc2/xorg-server-0.99.3/hw/xfree86/os-support«
make[3]: *** [all-recursive] Fehler 1
make[3]: Verlasse Verzeichnis
»/home/fkuehlin/src/xorg7rc2/xorg-server-0.99.3/hw/xfree86«
make[2]: *** [all] Fehler 2
make[2]: Verlasse Verzeichnis
»/home/fkuehlin/src/xorg7rc2/xorg-server-0.99.3/hw/xfree86«
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlasse Verzeichnis »/home/fkuehlin/src/xorg7rc2/xorg-server-0.99.3/hw«
make: *** [all-recursive] Fehler 1

Closer inspecition shows that the xf86drm.c version included in the tarball is
wrong (outdated?). For example it defines drmAgpAlloc with drm_handle_t *handle
while xf86drm.h and xf86drm.c from libdrm-1.0.5 both define it as unsigned long
*handle. Furthermore the monolithic tree doesn't have os-support/drm/xf86drm.c
any more. So I wonder how this file got into the modular Xorg server package. Is
it even needed?
Comment 1 Felix Kühling 2005-11-11 13:58:24 UTC
I have a workaround that just disables the os-support/drm build as it seems that
this entire directory is gone in the monolithic tree as well.

I can't easily run autoreconf on the release tarball so I fixed up
.../os-support/Makefile.in directly to get the build going again:

--- Makefile.in~        2005-11-10 02:56:14.000000000 -0500
+++ Makefile.in 2005-11-11 16:21:47.537578808 -0500
@@ -362,10 +362,9 @@
 sysconfdir = @sysconfdir@
 target_alias = @target_alias@
 xpconfigdir = @xpconfigdir@
-@DRI_TRUE@DRI_SUBDIRS = drm

-SUBDIRS = bus @XORG_OS_SUBDIR@ misc $(DRI_SUBDIRS)
-DIST_SUBDIRS = bsd bus drm misc linux lynxos solaris sysv sco usl
+SUBDIRS = bus @XORG_OS_SUBDIR@ misc
+DIST_SUBDIRS = bsd bus misc linux lynxos solaris sysv sco usl

 sdk_HEADERS = xf86_OSproc.h xf86_OSlib.h xf86_ansic.h xf86_libc.h xf86drm.h \
               xf86drmCompat.h assyntax.h xf86OSKbd.h xf86OSmouse.h




I guess the following change would do the trick for Makefile.am, but I can't
test it right now:

--- Makefile.am~        2005-11-08 17:47:56.000000000 -0500
+++ Makefile.am 2005-11-11 16:11:33.766886136 -0500
@@ -1,9 +1,5 @@
-if DRI
-DRI_SUBDIRS=drm
-endif
-
-SUBDIRS = bus @XORG_OS_SUBDIR@ misc $(DRI_SUBDIRS)
-DIST_SUBDIRS = bsd bus drm misc linux lynxos solaris sysv sco usl
+SUBDIRS = bus @XORG_OS_SUBDIR@ misc
+DIST_SUBDIRS = bsd bus misc linux lynxos solaris sysv sco usl

 sdk_HEADERS = xf86_OSproc.h xf86_OSlib.h xf86_ansic.h xf86_libc.h xf86drm.h \
               xf86drmCompat.h assyntax.h xf86OSKbd.h xf86OSmouse.h
Comment 2 Adam Jackson 2005-11-12 13:27:12 UTC
in the monolith, the libdrm source actually lives under os-support/linux/drm,
and then gets symlinked around for other platforms.  that was silly so we moved
it up a level in modular.

looks like we need to update libdrm in the server.  hooray.
Comment 3 Felix Kühling 2005-11-13 00:05:45 UTC
(In reply to comment #2)
> looks like we need to update libdrm in the server.  hooray.

Or make sure that the xserver build uses xf86drm.h from the xserver package
instead of the libdrm one.
Comment 4 Felix Kühling 2005-11-15 09:07:34 UTC
Reordering the include paths to make sure that xf86drm.h from the xorg-server
package is preferred doesn't seem to be trivial. It looks like I'd have to go
deep into autoconf to achive this. I gave up on this before I even started.

Instead I just copied the relevant xf86*.[ch] files over from libdrm and that
did the trick. The server builds and DRI works fine.
Comment 5 Adam Jackson 2005-11-30 17:10:18 UTC
i've nearly finished syncing libdrm upstream with the changes made to the copy
in xc (grr).  the last code change piece is the 32/64 compat fixes, which are
what actually cause the declaration mismatches you're seeing.

that, plus resyncing symlink.sh and the Imakefile to symlink properly and only
use the one copy of libdrm in the server... fun.  should have it sorted by tomorrow.
Comment 6 Adam Jackson 2005-12-01 13:14:29 UTC
libdrm 2.0 imported into extras.  os-support, libGL, and the XvMC libs all pull
from the extras copy now.  i am at one with the universe.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.