On Tue, Oct 08, 2002 at 05:04:18PM -0500, Branden Robinson wrote:
> On Tue, Oct 08, 2002 at 01:33:38PM -0600, Joel Baker wrote:
> > The good:
> >
> > After a bit of banging on things to force the circular dependancy path
> > between freetype and xfree86, and cribbing from the patches written for
> > 4.1.0, I'm close (very close) to having a set of patches to make xfree86
> > compile cleanly on the netbsd-i386 arch.
>
> Cool!
>
> > The bad:
> >
> > It requires some extensive patching. Some of this (strnlen portability
> > in xserver-wrapper.c, etc) has already been filed; the rest is waiting
> > on me getting the last bits hammered out. I've tried to make the patches
> > something that would be acceptable to upstream, but I have no idea if
> > they really will be. The most extensive, unsuprisingly, are to NetBSD.cf,
> > and are largely cribbed from linux.cf; however, changes to imake and
> > other things also need to happen.
>
> I gather that xc/config/cf/bsdLib.rules is going to be painful as well.
So I'm finding out. Not sure whether to patch this extensively, or just
generate a completely new file and patch NetBSD.cf to include that.
Probably patch.
> > The ugly:
> >
> > --- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.000000000 +0000
> > +++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.000000000
> > +0000
> > @@ -197 +196,0 @@
> > -etc/X11/xkb/symbols/alt
>
> Obsolete. See changelog.
Okay.
> > @@ -353 +351,0 @@
> > -usr/X11R6/bin/glxinfo
>
> I can't think of a reason this shouldn't be built. It should be
> possible to build the GLX extension, and therefore this client, even
> without DRI stuff.
See below.
> > @@ -356,0 +355 @@
> > +usr/X11R6/bin/kbd_mode
>
> I used to see this on Sun machines. You sure it's necessary with modern
> BSD kernels?
I'm not sure it is. I mostly don't know where/how to check whether it is,
or what it's supposed to do.
> > @@ -838,2 +836,0 @@
> > -usr/X11R6/include/X11/extensions/xf86rush.h
> > -usr/X11R6/include/X11/extensions/xf86rushstr.h
>
> Looks okay. This is the never-used Voodoo Rush extension. It builds on
> Linux/i386 but I've never heard of anyone using it for anything.
Okay. I'll yank those then.
> > @@ -5543,2 +5539,0 @@
> > -usr/X11R6/lib/libI810XvMC.a
> > -usr/X11R6/lib/libI810XvMC_pic.a
>
> This is new to XFree86 4.2. My guess is that it does something to hook
> into the (Linux) kernel to speak foul magic to the hardware. XvMC is
> Mark Vojkovich's motion compensation interface on top of the XVideo (Xv)
> extension. I'll cautiously assume that *BSD shouldn't be building this.
We can always put it back in if someone can show that it should build/work
on NetBSD platforms. However, at the moment, this is not listed as being
supportd on the NetBSD arch page in XFree86 docs. Will yank it.
> > @@ -5547,2 +5541,0 @@
> > -usr/X11R6/lib/libOSMesa.a
> > -usr/X11R6/lib/libOSMesa.so.3.3
>
> Nobody who builds DRI builds the offscreen Mesa library. Michel Dänzer
> understands better how this stuff works. (I.e., I don't know *why* it's
> called the "offscreen" Mesa library, or why 3D-accelerated GL rendering
> is considered "off-the-screen". Maybe it means the rendering isn't done
> into the framebuffer, a.k.a. "screen"?)
Er. Is that 'not building DRI implies not building libOSMesa' - IE, it
should be removed for non-Linux platforms?
> > @@ -5593 +5585,0 @@
> > -usr/X11R6/lib/libXxf86rush.a
>
> Voodoo Rush extension; see above.
Removed.
> > @@ -5602,0 +5595 @@
> > +usr/X11R6/lib/liboldX.so.6.0
>
> This goes in xlibs-dev.files. Already listed there.
Huh. xlibs-dev.files (and all of the MANIFESTs) have a static library
(/usr/X11R6/lib/liboldX.a) rather than a dynamic one. Maybe I need to tweak
a suitable part of the system and tell it to build a static liboldX?
> > @@ -5608 +5600,0 @@
> > -usr/X11R6/lib/libxrx.so.6.3
>
> Another extension no one uses. This is the Netscape Navigator plug in
> that lets you render the X server inside a browser window or some lunacy
> like that. I'm not sure there's a good reason it shouldn't build on
> *BSD versus Linux, but on the other hand there's probably not a good
> reason for *anyone* to build it.
Hmmm. I'll look into it, but after I do other things, then; tentatively
left in place, until I can figure out what is up with it on NetBSD.
> > @@ -5752,0 +5745 @@
> > +usr/X11R6/man/man1/kbd_mode.1x
>
> See above.
>
> > @@ -5754 +5746,0 @@
> > -usr/X11R6/man/man1/libxrx.1x
>
> See above.
Si.
> > @@ -7449 +7441 @@
> > -var/lib/xkb/README
> > +var/db/xkb/README
>
> I gather that *BSD cares not for the FHS. I remember having to persuade
> David Dawes to switch Linux back to /var/lib. Apparently the BSDs had
> already had enough.
True, mostly I just need to find the relevant thing and tweak it, I think.
> > DRI support is, of course, not relevant on the NetBSD kernel, and is not
> > present (and the related files have been removed already); the same goes
> > for the video4linux drivers. libGL and company, which didn't compile under
> > 4.1.0, now work (I think this is largely because the NetBSD port has
> > upgraded to version 1.6 in the meanwhile, and this is a major cleanup of
> > the NetBSD base system).
>
> You can build libGL without DRI support. Several Linux architectures do
> it.
Er, yes. Sorry, probably put too many things together in one paragraph
there. libGL does compile just fine, albeit with one caveat - see below.
> > I'm assuming that I can find a way to weak the /var/{lib,db}/xkb/README
> > location somewhere; I haven't dug into it yet.
>
> The answer to this question depends on which altar at which Debian/*BSD
> decides to worship; the FHS, or the other BSDs. Once that decision is
> made I'm happy to help you out with it. There's an Imake symbol called
> VarDbDirectory, I believe, which reflects the BSD experience of the
> XFree86 Core Team. :)
Policy says FHS; Debian/NetBSD, at least, is basically NetBSD kernel, libc,
and other required system libraries, but Debian-package-pure userspace,
filesystem arrangement, et al. The only exception so far is that, on the
1.6 port, ld.so and family live in /usr/libexec, but NetBSD native moved
this to /lib (as well as making /lib dynamic) in -current immediately after
the 1.6 release, so even that will probably go away before it requires a
Policy adjustment.
As such, I'll change the patch and tweak said symbol to put it where the
FHS says.
Now, the explanation for glxinfo (and it probably has much deeper
reprecussions): NetBSD includes bsdLib.rules, which does not have a number
of things from lnxLib.rules (the thing which made me realize this matters
is that it lacks SharedDepCplusplusLib, causing libGLU to be linked with
'gcc' instead of 'g++', causing glxinfo to fail when it tried to link
against the .so because the .so couldn't find various C++ system library
things).
Nor can I just drop in lnxLib.rules (unsuprisingly), because it wreaks a
lot of havoc in other places. So I'm going to have to general a patch set
for bsdLib, providing the bits from lnxLib that are required to make things
compile in a Debian-happy way.
Anyway, I'll be back once I beat on it some more. Any suggestions on what
to check to find out if kdb_mode is relevant would be appreciated.
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgpDJmzXSl_HX.pgp
Description: PGP signature