STILL building ephyr

[Dan Nicholson]

On Fri, Jul 11, 2008 at 10:53 AM, Chuck Robey <chuckr at telenix.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dan Nicholson wrote:
>> On Fri, Jul 11, 2008 at 5:54 AM, Chuck Robey <chuckr at telenix.org> wrote:
>>> Sure.  note that I left out nothing germane at all, though, did I?  The only cut
>>> things were useless repetitions of symbols which would come from the same source
>>> as the first one does.  I don't *think* my troubleshooting skills are so poor,
>>> it's my autotools wisdom which is stuck in reverse with most of the gear teeth
>>> busted off.  Plus, the (very embarrassing fact) that I go slow as molasses,
>>> getting in too much pain if I stay too long at the terminal.
>>
>> You might think there's no value in seeing the command failing, but if
>> it's a bug in the build, there's tons of information there.
>>
>>> Anyhow, just to be truly honest, this was a rebuild, from the top, after a
>>> thorough cleaning.  I sure wish all of the X-projects used distclean (some use
>>> realclean).
>>
>> Don't do that just yet. I'm think I found the issue.
>>
>>> here it is:
>>>
>>>
>>> gcc -I/usr/X11R7.4/include -I/usr/local/include -rdynamic -o Xephyr ephyrinit.o
>>>  -L/usr/X11R7.4/lib -L/usr/local/lib libxephyr.a libxephyr-hostx.a
>>> libxephyr-hostxv.a libxephyr-hostdri.a ../../../exa/.libs/libexa.a
>>> ../../../dix/.libs/libdix.a ../../../hw/kdrive/src/libkdrive.a
>>> ../../../hw/kdrive/src/libkdrivestubs.a ../../../config/libconfig.a
>>> ../../../fb/.libs/libfb.a ../../../mi/.libs/libmi.a
>>> ../../../xfixes/.libs/libxfixes.a ../../../Xext/.libs/libXext.a
>>> ../../../dbe/.libs/libdbe.a ../../../render/.libs/librender.a
>>> ../../../randr/.libs/librandr.a ../../../damageext/.libs/libdamageext.a
>>> ../../../miext/damage/.libs/libdamage.a ../../../miext/shadow/.libs/libshadow.a
>>> ../../../Xi/.libs/libXi.a ../../../xkb/.libs/libxkb.a
>>> ../../../xkb/.libs/libxkbstubs.a ../../../composite/.libs/libcomposite.a
>>> ../../../os/.libs/libos.a /usr/X11R7.4/lib/libpixman-1.so
>>> /usr/local/lib/libhal.so -lGL -lGLU -lGLw /usr/local/lib/libdbus-1.so -pthread
>>> /usr/X11R7.4/lib/libXfont.so /usr/local/lib/libfreetype.so
>>> /usr/X11R7.4/lib/libfontenc.so -lz /usr/X11R7.4/lib/libXv.so
>>> /usr/X11R7.4/lib/libXext.so /usr/X11R7.4/lib/libX11.so
>>> /usr/X11R7.4/lib/libXdmcp.so /usr/X11R7.4/lib/libXau.so -lcrypto -lrpcsvc -lm
>>> - -Wl,--rpath -Wl,/usr/X11R7.4/lib -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath
>>> - -Wl,/usr/X11R7.4/lib -Wl,--rpath -Wl,/usr/local/lib
>>> libxephyr-hostdri.a(ephyrglxext.o)(.text+0x1c): In function
>>> `ephyrHijackGLXExtension':
>>> : undefined reference to `Single_dispatch_info'
>
> Just before this fell into my email hopper, I'd found the symbol, yes, in
> libglx.  Why didn't *I* find it?  Because it haadn't been built yet.  I haven't
> yet finished working on this (I have no good reliable method, because I can't
> duplicate the autogen.sh step, to redo local parts of the build, so all of my
> testing does the whole tree, and takes forever, even on this fast machine, but I
> think that the issue is going to involve build order, because even if there'd
> been a linking step for libglx.a, it wasn't available to be linked yet.

I have a _very_ good feeling that GLX is not enabled in your build,
but DRI somehow is. So, libglx is not being built, but Xephyr thinks
it should build its DRI support. Xephyr's DRI support requires GLX,
but unfortunately we don't explicitly check for that. Again, what does
configure say about GLX? Can you do "egrep '(DRI|GLX)_TRUE'
config.status"?

Here's a patch you can try out (gmail will probably kill the formatting):

diff --git a/hw/kdrive/ephyr/Makefile.am b/hw/kdrive/ephyr/Makefile.am
index bf1f475..0980d33 100644
--- a/hw/kdrive/ephyr/Makefile.am
+++ b/hw/kdrive/ephyr/Makefile.am
@@ -12,8 +12,10 @@ LIBXEPHYR_HOSTXV=libxephyr-hostxv.a
 endif

 if DRI
+if GLX
 LIBXEPHYR_HOSTDRI=libxephyr-hostdri.a
 endif
+endif

 noinst_LIBRARIES = libxephyr-hostx.a $(LIBXEPHYR_HOSTXV)
$(LIBXEPHYR_HOSTDRI) libxephyr.a


> Hey, if you have a method, I'd appreciate an answer to a question that's nagging
> at me ... I have myself a Nvidia-compatible 8600GTS video card.  From what I've
> read so far, all of the Mesa (pr OpenGL) stuff is very very low level.  I
> *think* it need to be having  code that's quite specific to the actual graphic
> card, like I see defines for all of the Radeon stuff, and my own card, the
> Nvidia stuff, comes with it's own openGL libs.  What I'm asking is, how is it
> possible for there to be a mesa lib at all, why doesn't it need to be localized
> to each graphic card?  How could openGL work without having
> graphic-card-specific code?

That's what the DRI drivers are for (look in $libdir/dri). libGL (or
the xserver with AIGLX) just dlopens the hardware-specific DRI driver
or the software swrast driver at runtime.

--
Dan