Re: hurd-i386 updates
On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote:
> > Initially, I took the xfree86-4.3.0.dfsg.1-4 source package and the
> > k*BSD patch from
> > http://glibc-bsd.alioth.debian.org/patches/xfree86_4.3.0.dfsg.1-4.diff I
> > needed to tweak a couple of .install files to .install.hurd-i386 and fix
> > a parse error in xc/programs/xterm/xterm_io.h or similar introduced in
> > the k*BSD patch but that was it.
>
> Okay. This xterm_io.h problem is not present in the stock XFree86
> packages, though?
No, it is not. It also got fixed in the k*BSD branch a while ago.
> > The main questions are the following defines, which were missing in
> > gnu.cf (diff from linux.cf to gnu.cf):
> >
> > -# define StaticNeedsPicForShared NO
> > -# define KernelVersionInBanner YES
> >
> > Should we have those? What is the default for the first? I did not add
> > them for now.
>
> StaticNeedsPicForShared is upstream's solution to the notorious
> PIC-symbols-in-static-libraries problem[1][2]. What upstream does is, for
> some architectures, stuff the PIC symbols into the ordinary static library
> .a files. As noted in the Debian section of linux.cf, we don't use this
> approach. What we do is always leave the PIC information out of static
> libraries, and provide _pic.a versions of static libraries (in
> xlibs-static-pic) for applications that "need" to dlopen() a statically
> linked object.
Ah, ok.
> I would #define StaticNeedsPicForShared NO for the Hurd, assuming your
> packages are going to be pretty congruent with the Linux ones.
Judging from xfree86.cf and Imake.tmpl, it seems StaticNeedsPicForShared
default to NO anyway for i386, but that should be synced, yes.
> KernelVersionInBanner: this is a thing used only by the XFree86 X server.
> This symbol leads us to xc/programs/Xserver/hw/xfree86/common/Imakefile,
> where we see that it passes the flag -DXF86_KERNEL_VER_IN_BANNER to the
> compiler when building xc/programs/Xserver/hw/xfree86/common/xf86Init.c.
> Given that I don't expect the Hurd to support Linux's peculiar /proc
> namespace as used above, I would expect leaving this Imake parameter
> undefined, or #defining it to NO, would be the right choice for the Hurd,
> until and unless you want to write a Hurd-specific
> xf86PrintOSKernelString() function.
Indeed, the Hurd has no /proc at all, so this should be defined to NO,
thanks.
> I glanced over your patch and it looks fine. I'll take a closer look
> before committing.
I forgot in my last mail to credit Robert Millan with the (new)
803_gnu_xterm_openpty.diff and 804_gnu_xdm.diff patches, which I pulled
out of his k*BSD diff.
No changes to the maintainer files other than the MANIFEST update are
necessary. I could provide a very cut-down version of the gnu.cf diff
without syncing to linux.cf, but I think syncing is a worthwhile goal
for now.
> Would you like to take over as the XSF Hurd committer?
Well, I tried to not get wet too much while poking around with Imake and
*.cf stuff. Also, I hope that there will be no more big syncing/porting
involved until Debian moves to an X implementation with a sane build
system. But yeah, I could care about this, I've since subscribed to
debian-x and will try to keep current with the flow.
cheers,
Michael
Reply to: