Re: hurd-i386 updates
On Thu, Jul 29, 2004 at 02:05:27PM +0200, Michael Banck wrote: > > +-#ifndef > +-#define CppCmd/lib/cpp > ++#ifndef CppCmd > ++#define CppCmd/usr/bin/cpp > > I was under the impression that k*BSD does not have a /lib/cpp symlink > and that's why the patch is in there. As the symlink is present on > GNU/Linux as well, I rather assume that GNU/Hurd did not have > /usr/bin/cpp back in the days. IIRC, this patch is a modification from a previous one that made it /usr/bin/cpp-3.3. I just replaced the /usr/bin/cpp-3.3 with /usr/bin/cpp because we didn't have cpp-3.3 on GNU/k*BSD at the time. This is no longer true, so just ignore this. All Debian ports should have /lib/cpp, it's in the cpp package. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: hurd-i386 updates
On Thu, Jul 29, 2004 at 03:43:17AM -0500, Branden Robinson wrote: > > I'm dropping the following part of #804 because: > > 1) It doesn't actually have anything to do with GNU/Hurd, AFAICT > 2) We don't have patches to support the symbols KNetBSDArchitecture and >KOpenBSDArchitecture yet anyway, so these symbols will never be defined. Yeah that's ok. Please don't bother with the GNU/k*BSD parts of my patches (even merged ones, in patches/82*). When integration of GNU/Hurd support is finished, my GNU/k*BSD patches will become smaller and easier to integrate. I'll have a look then. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: hurd-i386 updates
On Thu, Jul 29, 2004 at 03:43:17AM -0500, Branden Robinson wrote: > On Wed, Jul 28, 2004 at 07:31:39PM +0200, Michael Banck wrote: > > #803 and #804 are needed to properly build on GNU and are taken out of > > Robert Millan's k*BSD tree. > [...] > I'm dropping the following part of #804 because: > 1) It doesn't actually have anything to do with GNU/Hurd, AFAICT > 2) We don't have patches to support the symbols KNetBSDArchitecture and >KOpenBSDArchitecture yet anyway, so these symbols will never be defined. Yeah, I missed those when I trimmed down the patches. Michael
Re: hurd-i386 updates
On Thu, Jul 29, 2004 at 03:31:50AM -0500, Branden Robinson wrote: > > I'm no PAM guru, so I don't know about that change (I've seen Branden > > has marked it as TODO on top of #800), > > Technically, it's marked XXX, which means I don't know what to do about it. > I'm leaving it up the actual Hurd porters to tell me. Well, the current patch works, so I guess there is no reason to keep it out. > I actually don't understand the above; sorry. Not sure which part of the following two you are referring to here, so I elaborate on both: > > but I merged that back from my intial diff and the build was fine (I did > > not try building without 'define PamLibraries'). xfree86[...]-6 had PamLibraries defined, while current SVN does not. I haven't tried to build the unpatched SVN trunk, but as hurd-i386 has those libraries, I see no reason why gnu.cf should differ from linux.cf here today, even more so as xfree86 builds fine with them. Also, PamMiscLibraries are avaible as well, so I added those. > > Changing the cpp command line is only needed for k*BSD AFAIK, but it > > does not hurt to sync that with linux.cf as well. +-#ifndef +-#define CppCmd/lib/cpp ++#ifndef CppCmd ++#define CppCmd/usr/bin/cpp I was under the impression that k*BSD does not have a /lib/cpp symlink and that's why the patch is in there. As the symlink is present on GNU/Linux as well, I rather assume that GNU/Hurd did not have /usr/bin/cpp back in the days. Well, either way works, but it is /usr/bin/cpp in linux.cf as well, so this syncs this back. This part of the patch is probably not required though, so if you don't like it, just drop it. > I'll also take care of updating the mir-false-* files. Oh, another thing I didn't know about :) Michael
Re: hurd-i386 updates
On Wed, Jul 28, 2004 at 07:31:39PM +0200, Michael Banck wrote: > #803 and #804 are needed to properly build on GNU and are taken out of > Robert Millan's k*BSD tree. [...] I'm dropping the following part of #804 because: 1) It doesn't actually have anything to do with GNU/Hurd, AFAICT 2) We don't have patches to support the symbols KNetBSDArchitecture and KOpenBSDArchitecture yet anyway, so these symbols will never be defined. > +diff -ur xc/programs/xdm.old/config/Imakefile > xc/programs/xdm/config/Imakefile > +--- xc/programs/xdm.old/config/Imakefile 2003-11-29 16:07:56.0 > +0100 > xc/programs/xdm/config/Imakefile 2003-11-29 16:09:08.0 +0100 > +@@ -9,7 +9,7 @@ > + > + all:: Xservers.ws xdm-config Xservers Xresources > + > +-#if defined(i386Architecture) && (defined(NetBSDArchitecture) || > defined(OpenBSDArchitecture)) > ++#if defined(i386Architecture) && (defined(KNetBSDArchitecture) || > defined(KOpenBSDArchitecture)) > + DEFAULTVT=vt05 > + #endif > + -- G. Branden Robinson| You could wire up a dead rat to a Debian GNU/Linux | DIMM socket and the PC BIOS memory [EMAIL PROTECTED] | test would pass it just fine. http://people.debian.org/~branden/ | -- Ethan Benson signature.asc Description: Digital signature
Re: hurd-i386 updates
On Wed, Jul 28, 2004 at 07:31:39PM +0200, Michael Banck wrote: > I've made another patch against current svn. It's much smaller now, > thanks to Branden's resyncing. That's good to hear. > Defining libpng and groff in gnu.cf results in some stuff getting built, > so MANIFEST.hurd-i386.all is obsolete now and the diff between > MANIFEST.i386.in and MANIFEST.hurd-i386.in only includes stuff like DRI, > glide and so on. Very cool. It's nice to know there's much more parity now. > I'm no PAM guru, so I don't know about that change (I've seen Branden > has marked it as TODO on top of #800), Technically, it's marked XXX, which means I don't know what to do about it. I'm leaving it up the actual Hurd porters to tell me. > but I merged that back from my intial diff and the build was fine (I did > not try building without 'define PamLibraries'). Changing the cpp command > line is only needed for k*BSD AFAIK, but it does not hurt to sync that > with linux.cf as well. I actually don't understand the above; sorry. > #803 and #804 are needed to properly build on GNU and are taken out of > Robert Millan's k*BSD tree. Okay. > I've attached the updated fix. It applies and debian/rules setup runs > throught fine. Note that I did not include the diff to remove > MANIFEST.hurd-i386.all in order to not bloat it unnecessary. That file > should just be removed. I can resend the full diff if necessary. No, that's okay. I'll also take care of updating the mir-false-* files. -- G. Branden Robinson| Debian GNU/Linux | Ignorantia judicis est calamitas [EMAIL PROTECTED] | innocentis. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: hurd-i386 updates
Hi, On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote: > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > It would be nice if hurd-i386 could be back on line with the next > > upload. > > Yes it would. > > I glanced over your patch and it looks fine. I'll take a closer look > before committing. I've made another patch against current svn. It's much smaller now, thanks to Branden's resyncing. Defining libpng and groff in gnu.cf results in some stuff getting built, so MANIFEST.hurd-i386.all is obsolete now and the diff between MANIFEST.i386.in and MANIFEST.hurd-i386.in only includes stuff like DRI, glide and so on. I'm no PAM guru, so I don't know about that change (I've seen Branden has marked it as TODO on top of #800), but I merged that back from my intial diff and the build was fine (I did not try building without 'define PamLibraries'). Changing the cpp command line is only needed for k*BSD AFAIK, but it does not hurt to sync that with linux.cf as well. #803 and #804 are needed to properly build on GNU and are taken out of Robert Millan's k*BSD tree. I've attached the updated fix. It applies and debian/rules setup runs throught fine. Note that I did not include the diff to remove MANIFEST.hurd-i386.all in order to not bloat it unnecessary. That file should just be removed. I can resend the full diff if necessary. cheers, Michael diff -Naur debian/MANIFEST.hurd-i386.in debian.new/MANIFEST.hurd-i386.in --- debian/MANIFEST.hurd-i386.in2004-07-28 13:27:31.0 +0200 +++ debian.new/MANIFEST.hurd-i386.in2004-07-28 13:26:16.0 +0200 @@ -505,6 +505,7 @@ usr/X11R6/bin/xclock usr/X11R6/bin/xcmsdb usr/X11R6/bin/xconsole +usr/X11R6/bin/xcursorgen usr/X11R6/bin/xcutsel usr/X11R6/bin/xditview usr/X11R6/bin/xdm @@ -1142,6 +1143,131 @@ usr/X11R6/lib/X11/fonts/util/map-ISO8859-9 usr/X11R6/lib/X11/fonts/util/map-JISX0201.1976-0 usr/X11R6/lib/X11/fonts/util/map-KOI8-R +usr/X11R6/lib/X11/icons/handhelds/cursors/X_cursor +usr/X11R6/lib/X11/icons/handhelds/cursors/based_arrow_down +usr/X11R6/lib/X11/icons/handhelds/cursors/based_arrow_up +usr/X11R6/lib/X11/icons/handhelds/cursors/bottom_left_corner +usr/X11R6/lib/X11/icons/handhelds/cursors/bottom_right_corner +usr/X11R6/lib/X11/icons/handhelds/cursors/bottom_side +usr/X11R6/lib/X11/icons/handhelds/cursors/bottom_tee +usr/X11R6/lib/X11/icons/handhelds/cursors/center_ptr +usr/X11R6/lib/X11/icons/handhelds/cursors/circle +usr/X11R6/lib/X11/icons/handhelds/cursors/cross +usr/X11R6/lib/X11/icons/handhelds/cursors/dot +usr/X11R6/lib/X11/icons/handhelds/cursors/dotbox +usr/X11R6/lib/X11/icons/handhelds/cursors/double_arrow +usr/X11R6/lib/X11/icons/handhelds/cursors/draped_box +usr/X11R6/lib/X11/icons/handhelds/cursors/fleur +usr/X11R6/lib/X11/icons/handhelds/cursors/gumby +usr/X11R6/lib/X11/icons/handhelds/cursors/hand2 +usr/X11R6/lib/X11/icons/handhelds/cursors/left_ptr +usr/X11R6/lib/X11/icons/handhelds/cursors/left_ptr_watch +usr/X11R6/lib/X11/icons/handhelds/cursors/left_side +usr/X11R6/lib/X11/icons/handhelds/cursors/left_tee +usr/X11R6/lib/X11/icons/handhelds/cursors/ll_angle +usr/X11R6/lib/X11/icons/handhelds/cursors/pencil +usr/X11R6/lib/X11/icons/handhelds/cursors/right_ptr +usr/X11R6/lib/X11/icons/handhelds/cursors/right_side +usr/X11R6/lib/X11/icons/handhelds/cursors/right_tee +usr/X11R6/lib/X11/icons/handhelds/cursors/sb_h_double_arrow +usr/X11R6/lib/X11/icons/handhelds/cursors/sb_right_arrow +usr/X11R6/lib/X11/icons/handhelds/cursors/sb_up_arrow +usr/X11R6/lib/X11/icons/handhelds/cursors/sb_v_double_arrow +usr/X11R6/lib/X11/icons/handhelds/cursors/shuttle +usr/X11R6/lib/X11/icons/handhelds/cursors/top_left_corner +usr/X11R6/lib/X11/icons/handhelds/cursors/top_right_corner +usr/X11R6/lib/X11/icons/handhelds/cursors/top_side +usr/X11R6/lib/X11/icons/handhelds/cursors/top_tee +usr/X11R6/lib/X11/icons/handhelds/cursors/watch +usr/X11R6/lib/X11/icons/handhelds/cursors/xterm +usr/X11R6/lib/X11/icons/redglass/cursors/X_cursor +usr/X11R6/lib/X11/icons/redglass/cursors/based_arrow_down +usr/X11R6/lib/X11/icons/redglass/cursors/based_arrow_up +usr/X11R6/lib/X11/icons/redglass/cursors/bottom_left_corner +usr/X11R6/lib/X11/icons/redglass/cursors/bottom_right_corner +usr/X11R6/lib/X11/icons/redglass/cursors/bottom_side +usr/X11R6/lib/X11/icons/redglass/cursors/bottom_tee +usr/X11R6/lib/X11/icons/redglass/cursors/center_ptr +usr/X11R6/lib/X11/icons/redglass/cursors/circle +usr/X11R6/lib/X11/icons/redglass/cursors/cross +usr/X11R6/lib/X11/icons/redglass/cursors/dot +usr/X11R6/lib/X11/icons/redglass/cursors/dotbox +usr/X11R6/lib/X11/icons/redglass/cursors/double_arrow +usr/X11R6/lib/X11/icons/redglass/cursors/draped_box +usr/X11R6/lib/X11/icons/redglass/cursors/fleur +usr/X11R6/lib/X11/icons/redglass/cursors/gumby +usr/X11R6/lib/X11/icons/redglass/cursors/hand2 +usr/X11R6/lib/X11/icons/redglass/cursors/left_ptr +usr/X11R6/lib/X11/icons/redglass/cursors/left_ptr_watch +usr/X11R6/lib/X11/icons/redglass/cursor
Re: Patch 031 (was: Re: hurd-i386 updates)
On Mon, Jul 26, 2004 at 04:40:59PM -0500, Branden Robinson wrote: > > > On Wed, Jul 14, 2004 at 12:16:20PM -0500, Branden Robinson wrote: > > > > > > > > Hmm, well, how about this? > > > > > > > > --- xc/programs/glxinfo/Imakefile~ 2004-07-14 12:03:14.0 > > > > -0500 > > > > +++ xc/programs/glxinfo/Imakefile 2004-07-14 12:12:57.0 > > > > -0500 > > > > @@ -15,6 +15,6 @@ > > > > > > > > #endif > > > > > > > > - SYS_LIBRARIES = MathLibrary -lstdc++ > > > > + SYS_LIBRARIES = MathLibrary > > > > > > > > -SimpleProgramTarget(glxinfo) > > > > +SimpleCplusplusProgramTarget(glxinfo) > > Any progress on this? If it looks good, please commit the fix to the > trunk (modifying patch #031 as needed). As you already noticed, I messed up when committing this. I'll commit it to trunk properly once 1674 is reverted (see my reply in the other thread). -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Patch 031 (was: Re: hurd-i386 updates)
On Mon, Jul 19, 2004 at 02:10:01PM -0600, Joel Baker wrote: > On Mon, Jul 19, 2004 at 04:28:24AM +0200, Robert Millan wrote: > > On Wed, Jul 14, 2004 at 12:16:20PM -0500, Branden Robinson wrote: > > > > > > Hmm, well, how about this? > > > > > > --- xc/programs/glxinfo/Imakefile~2004-07-14 12:03:14.0 > > > -0500 > > > +++ xc/programs/glxinfo/Imakefile 2004-07-14 12:12:57.0 -0500 > > > @@ -15,6 +15,6 @@ > > > > > > #endif > > > > > > - SYS_LIBRARIES = MathLibrary -lstdc++ > > > + SYS_LIBRARIES = MathLibrary > > > > > > -SimpleProgramTarget(glxinfo) > > > +SimpleCplusplusProgramTarget(glxinfo) > > > > > > Seems to build something. Seems to work...but I'm GNU/Linux on PowerPC. > > > > Seems like it. As long g++ was used, it should be ok. > > > > I'll test this on GNU/kFreeBSD and commit. > > *dons part-time Debian GCC & Debian X committer hats together* > > This looks correct from past work on the NetBSD patches, and using g++ > rather than -lstdc++ is *absolutely* the correct solution. Any progress on this? If it looks good, please commit the fix to the trunk (modifying patch #031 as needed). -- G. Branden Robinson| Never attribute to conspiracy that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by economics. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Patch 031 (was: Re: hurd-i386 updates)
On Mon, Jul 19, 2004 at 04:28:24AM +0200, Robert Millan wrote: > On Wed, Jul 14, 2004 at 12:16:20PM -0500, Branden Robinson wrote: > > > > Hmm, well, how about this? > > > > --- xc/programs/glxinfo/Imakefile~ 2004-07-14 12:03:14.0 -0500 > > +++ xc/programs/glxinfo/Imakefile 2004-07-14 12:12:57.0 -0500 > > @@ -15,6 +15,6 @@ > > > > #endif > > > > - SYS_LIBRARIES = MathLibrary -lstdc++ > > + SYS_LIBRARIES = MathLibrary > > > > -SimpleProgramTarget(glxinfo) > > +SimpleCplusplusProgramTarget(glxinfo) > > > > Seems to build something. Seems to work...but I'm GNU/Linux on PowerPC. > > Seems like it. As long g++ was used, it should be ok. > > I'll test this on GNU/kFreeBSD and commit. *dons part-time Debian GCC & Debian X committer hats together* This looks correct from past work on the NetBSD patches, and using g++ rather than -lstdc++ is *absolutely* the correct solution. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpkhfdRozg9G.pgp Description: PGP signature
Re: hurd-i386 updates
On Wed, Jul 14, 2004 at 11:57:42AM -0500, Branden Robinson wrote: > On Tue, Jul 13, 2004 at 02:47:46PM +0200, Robert Millan wrote: > > Actualy, my k*BSD.cf files only contain kernel stuff. The Glibc-based > > GNU/k*BSD ports use gnu.cf directly (as Glibc systems this works fine). > > > > Now that Michael has overhauled gnu.cf, my idea is to merge the (minor) > > k*BSD > > bits into a conditionalised section in gnu.cf, together with a bunch of > > conditionalised sections copied from linux.cf. This way we can get all > > Glibc-based ports to use the same base configuration. > > > > As for non-Glibc ports, we will have to split the Debian bits out of gnu.cf > > into, say, debian.cf. Then both gnu.cf and NetBSD.cf can use that. > > > > What do you people think? > > I say do what you like, but keep in mind 1) that we no longer really have a > relationship with XFree86 upstream, at least when it comes to Imakefiles > and 2) no one other than XFree86 appears to be interested in retraining > Imake as a build system. > > In other words, my ordinary caution about major overhauls in this part of > the tree is not engaged, but please don't spend time engineering a solution > for the ages, as the rest of the X community seems pretty interested in > making sure Imake doesn't live very much longer. > > (Of course, it often happens that deprecating things doesn't always > actually make them go away...) Agreed in general. Depending on how my work life goes and a few other things, I may not get around to doing serious revamping of the NetBSD branch until we've started to move to a saner build system anyway... but, on the whole, I think that splitting debian.cf from gnu.cf from linux.cf from NetBSD.cf is probably sane (albeit the latter may end up named something else just because it shares *almost* nothing with NetBSD-native configs; the NetBSD kernel stuff just ain't that exciting, and it still has a GNU userland, just not a GNU libc). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpjxqv0je9ew.pgp Description: PGP signature
Re: hurd-i386 updates
On Wed, Jul 14, 2004 at 11:57:42AM -0500, Branden Robinson wrote: > > I say do what you like, but keep in mind 1) that we no longer really have a > relationship with XFree86 upstream, at least when it comes to Imakefiles > and 2) no one other than XFree86 appears to be interested in retraining > Imake as a build system. > > In other words, my ordinary caution about major overhauls in this part of > the tree is not engaged, but please don't spend time engineering a solution > for the ages, as the rest of the X community seems pretty interested in > making sure Imake doesn't live very much longer. Yeah, this makes a lot of sense. I've wished imake went eat rotten flesh for a bunch of times now.. ;) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion)
Re: Patch 031 (was: Re: hurd-i386 updates)
On Wed, Jul 14, 2004 at 12:16:20PM -0500, Branden Robinson wrote: > > Hmm, well, how about this? > > --- xc/programs/glxinfo/Imakefile~2004-07-14 12:03:14.0 -0500 > +++ xc/programs/glxinfo/Imakefile 2004-07-14 12:12:57.0 -0500 > @@ -15,6 +15,6 @@ > > #endif > > - SYS_LIBRARIES = MathLibrary -lstdc++ > + SYS_LIBRARIES = MathLibrary > > -SimpleProgramTarget(glxinfo) > +SimpleCplusplusProgramTarget(glxinfo) > > Seems to build something. Seems to work...but I'm GNU/Linux on PowerPC. Seems like it. As long g++ was used, it should be ok. I'll test this on GNU/kFreeBSD and commit. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion)
Re: hurd-i386 updates
On Wed, Jul 14, 2004 at 12:00:13PM -0500, Branden Robinson wrote: > On Tue, Jul 13, 2004 at 09:34:06PM +0200, Michael Banck wrote: > > On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote: > > > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > > > -# define FontLibSharedFreeType NO > Are you sure the following comment in linux.cf does not explain this issue? > 202 /* > 203 * We want to be sure that the normal XFree86 X server and the > debugging X > 204 * server use the same FreeType2 library. We'd *like* it if we could > 205 * achieve this by both packages dynamically linking against the > system's > 206 * FreeType2 library; however, the normal X server package > 207 * (xserver-xfree86) *cannot* be built dynamically linked against the > 208 * FreeType2 library when the module loader is enabled because of > 209 * code/design issues. Therefore, we encapsulate XFree86's internal > "fork" > 210 * of the FreeType2 library into *both* xserver-xfree86 and > 211 * xserver-xfree86-dbg. When it becomes possible to build the > 212 * module-loading server against an external FreeType2 shared > library, we > 213 * can drop this define: > 214 */ > 215 # define FontLibSharedFreeType NO Well, of course I read the comment and subsequently decided to #define the FontLibSharedFreeType based on it, but afterwards I was not able to figure out the Imake stuff and build logs to see why this really works. Oh well, I guess it is clear that FontLibSharedFreeType should be disabled on hurd-i386. cheers, Michael
Re: Patch 031 (was: Re: hurd-i386 updates)
On Tue, Jul 13, 2004 at 03:49:50PM +0200, Robert Millan wrote: > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > Hello, > > > > I've brought the hurd-i386 port of xfree86 back on track. > > Btw, I'm trying to fix patch 031 which was added for GNU/Hurd some time ago > and it is wrong. > > 031 adds a -lstdc++ flag in order to link glxinfo, but it should be telling > imake to use g++ instead of gcc. > > I've been unable to determine the iMakefile magic to do that, though. Can > someone enlighten me? Hmm, well, how about this? --- xc/programs/glxinfo/Imakefile~ 2004-07-14 12:03:14.0 -0500 +++ xc/programs/glxinfo/Imakefile 2004-07-14 12:12:57.0 -0500 @@ -15,6 +15,6 @@ #endif - SYS_LIBRARIES = MathLibrary -lstdc++ + SYS_LIBRARIES = MathLibrary -SimpleProgramTarget(glxinfo) +SimpleCplusplusProgramTarget(glxinfo) Seems to build something. Seems to work...but I'm GNU/Linux on PowerPC. $ ldd ./glxinfo libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x0ff5d000) libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x0fead000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0fe7b000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0fd82000) libpthread.so.0 => /lib/libpthread.so.0 (0x0fd11000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0fc29000) libm.so.6 => /lib/libm.so.6 (0x0fb95000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0fb68000) libc.so.6 => /lib/libc.so.6 (0x0fa0a000) libdl.so.2 => /lib/libdl.so.2 (0x0f9e7000) /lib/ld.so.1 => /lib/ld.so.1 (0x3000) $ ldd $(which glxinfo) libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x0ff5d000) libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x0fead000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0fe7b000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0fd82000) libpthread.so.0 => /lib/libpthread.so.0 (0x0fd11000) libm.so.6 => /lib/libm.so.6 (0x0fc7d000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0fb95000) libc.so.6 => /lib/libc.so.6 (0x0fa37000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0fa0a000) libdl.so.2 => /lib/libdl.so.2 (0x0f9e7000) /lib/ld.so.1 => /lib/ld.so.1 (0x3000) -- G. Branden Robinson|No executive devotes much effort to Debian GNU/Linux |proving himself wrong. [EMAIL PROTECTED] |-- Laurence J. Peter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: hurd-i386 updates
On Tue, Jul 13, 2004 at 09:34:06PM +0200, Michael Banck wrote: > On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote: > > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > > -# define FontLibSharedFreeType NO > > > > > > This one causes a build failure even with the current trunk, as > > > xc/lib/font/libXFont apparently does not get built on Linux and > > > xc/lib/font/Freetype/fcfuncs.c needs to be updated for current > > > libfreetype6. I added the #define to gnu.cf as well, is that reasonable? > > > > Uh, you lost me on this one. Can we break this issue out into a separate > > mail. I get confused quickly when it comes to the Byzantine mess that is > > font support in X. > > Ok, so this is really hairy to figure out. I tried a lot of stuff on and > off, so I'm not sure whether the following is completely accurate and I > found it out more by empirical than methodical research: > > 099b_Xft_FreeType_2.1.7_build_fix.diff does not touch > xc/lib/font/Freetype/ftfuncs.c although that file would need the same > kind of fixes I believe. > > The error occurs when building the static xserver: [...] > However, grepping through a xfree86 build log on GNU/Linux, I can't > really tell what makes the difference here, ftfuncs.c seems to get > compiled both by the shared and static XServer on GNU/Hurd and > GNU/Linux. So I'm not sure what exactly was the cause, but at some point > I was quite certain that defining the above variable helped :-/ Are you sure the following comment in linux.cf does not explain this issue? 202 /* 203 * We want to be sure that the normal XFree86 X server and the debugging X 204 * server use the same FreeType2 library. We'd *like* it if we could 205 * achieve this by both packages dynamically linking against the system's 206 * FreeType2 library; however, the normal X server package 207 * (xserver-xfree86) *cannot* be built dynamically linked against the 208 * FreeType2 library when the module loader is enabled because of 209 * code/design issues. Therefore, we encapsulate XFree86's internal "fork" 210 * of the FreeType2 library into *both* xserver-xfree86 and 211 * xserver-xfree86-dbg. When it becomes possible to build the 212 * module-loading server against an external FreeType2 shared library, we 213 * can drop this define: 214 */ 215 # define FontLibSharedFreeTypeNO -- G. Branden Robinson| When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: hurd-i386 updates
On Tue, Jul 13, 2004 at 02:47:46PM +0200, Robert Millan wrote: > Actualy, my k*BSD.cf files only contain kernel stuff. The Glibc-based > GNU/k*BSD ports use gnu.cf directly (as Glibc systems this works fine). > > Now that Michael has overhauled gnu.cf, my idea is to merge the (minor) k*BSD > bits into a conditionalised section in gnu.cf, together with a bunch of > conditionalised sections copied from linux.cf. This way we can get all > Glibc-based ports to use the same base configuration. > > As for non-Glibc ports, we will have to split the Debian bits out of gnu.cf > into, say, debian.cf. Then both gnu.cf and NetBSD.cf can use that. > > What do you people think? I say do what you like, but keep in mind 1) that we no longer really have a relationship with XFree86 upstream, at least when it comes to Imakefiles and 2) no one other than XFree86 appears to be interested in retraining Imake as a build system. In other words, my ordinary caution about major overhauls in this part of the tree is not engaged, but please don't spend time engineering a solution for the ages, as the rest of the X community seems pretty interested in making sure Imake doesn't live very much longer. (Of course, it often happens that deprecating things doesn't always actually make them go away...) -- G. Branden Robinson|Nixon was so crooked that he needed Debian GNU/Linux |servants to help him screw his [EMAIL PROTECTED] |pants on every morning. http://people.debian.org/~branden/ |-- Hunter S. Thompson signature.asc Description: Digital signature
Re: hurd-i386 updates
On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote: > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > -# define FontLibSharedFreeType NO > > > > This one causes a build failure even with the current trunk, as > > xc/lib/font/libXFont apparently does not get built on Linux and > > xc/lib/font/Freetype/fcfuncs.c needs to be updated for current > > libfreetype6. I added the #define to gnu.cf as well, is that reasonable? > > Uh, you lost me on this one. Can we break this issue out into a separate > mail. I get confused quickly when it comes to the Byzantine mess that is > font support in X. Ok, so this is really hairy to figure out. I tried a lot of stuff on and off, so I'm not sure whether the following is completely accurate and I found it out more by empirical than methodical research: 099b_Xft_FreeType_2.1.7_build_fix.diff does not touch xc/lib/font/Freetype/ftfuncs.c although that file would need the same kind of fixes I believe. The error occurs when building the static xserver: gcc -c -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-proto types -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I../.. /../include/fonts -I../include -I../../../exports/include/X11 -I../../../programs/Xserver/incl ude -I/usr/include/freetype2 -I/usr/include/freetype2/include -I../../../exports/include -I../../.. -I.. /../../exports/include -I/usr/X11R6/include -D__GNU__ -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOUR CE -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension-DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE-DBUILDDEBUG -DXResExtens ion -DX_BYTE_ORDER=X_LITTLE_ENDIAN -O0 -g ftfunc In file included from ftfuncs.c:40: /usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h' hasn't been included yet!" /usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use macros to include FreeType header files." /usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:" /usr/include/freetype2/freetype/freetype.h:23:2: #error " #include " /usr/include/freetype2/freetype/freetype.h:24:2: #error " #include FT_FREETYPE_H" In file included from ftfuncs.c:48: ft.h:73: warning: redundant redeclaration of `FreeTypeRegisterFontFileFunctions' in same scope ../../../include/fonts/fontproto.h:91: warning: previous declaration of `FreeTypeRegisterFontFileFunctions' make[6]: *** [ftfuncs.o] Error 1 make[6]: Leaving directory `/home/mbanck/xfree86-4.3.0.dfsg.1.current/build-tree/xc-xserver-xfree86-dbg/l ib/font/FreeType' make[5]: *** [FreeType] Error 2 make[5]: Leaving directory `/home/mbanck/xfree86-4.3.0.dfsg.1.current/build-tree/xc-xserver-xfree86-dbg/lib/font' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/mbanck/xfree86-4.3.0.dfsg.1.current/build-tree/xc-xserver-xfree86-dbg/lib' making all in ./programs... The build goes on and later fails when linking XFree86: gcc -o XFree86 [...] ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lfreetype -lz -lm -Wl,-rpath-link=../../exports/lib gcc: ../../lib/font/libXfont.a: No such file or directory make[5]: *** [XFree86] Error 1 make[5]: Leaving directory `/home/mbanck/xfree86-4.3.0.dfsg.1.current/build-tree/xc-xserver-xfree86-dbg/programs/Xserver' However, grepping through a xfree86 build log on GNU/Linux, I can't really tell what makes the difference here, ftfuncs.c seems to get compiled both by the shared and static XServer on GNU/Hurd and GNU/Linux. So I'm not sure what exactly was the cause, but at some point I was quite certain that defining the above variable helped :-/ Michael
Re: Patch 031 (was: Re: hurd-i386 updates)
On Tue, Jul 13, 2004 at 03:49:50PM +0200, Robert Millan wrote: > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > Hello, > > > > I've brought the hurd-i386 port of xfree86 back on track. > > Btw, I'm trying to fix patch 031 which was added for GNU/Hurd some time ago > and it is wrong. > > 031 adds a -lstdc++ flag in order to link glxinfo, but it should be telling > imake to use g++ instead of gcc. > > I've been unable to determine the iMakefile magic to do that, though. Can > someone enlighten me? As a data point, glxinfo builds and runs fine with my patch (which does not touch 031). glxgears runs as well, though it's quite flakey due to non-optimized scheduling in Mach/Hurd I guess. Michael
Patch 031 (was: Re: hurd-i386 updates)
On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > Hello, > > I've brought the hurd-i386 port of xfree86 back on track. Btw, I'm trying to fix patch 031 which was added for GNU/Hurd some time ago and it is wrong. 031 adds a -lstdc++ flag in order to link glxinfo, but it should be telling imake to use g++ instead of gcc. I've been unable to determine the iMakefile magic to do that, though. Can someone enlighten me? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion)
Re: hurd-i386 updates
On Tue, Jul 13, 2004 at 02:54:13PM +0200, Robert Millan wrote:
> On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote:
> >125 static void
> >126 xf86PrintOSKernelString(void)
> >127 {
>
> >140 if ((infile = fopen("/proc/version", "r")) != NULL)
>
> Doesn't look much different from `uname -srv`. We could use this hack for
> Linux and a simple uname() call otherwise.
>
> But I don't see why this requires a macro in the conffile. Can't we just use
> #ifdef __linux__ in the code?
It used to be #ifdef REDHAT_CUSTOM or something, but I changed it when I
stole it.
--
Daniel Stone<[EMAIL PROTECTED]>
Debian: the universal operating system http://www.debian.org
signature.asc
Description: Digital signature
Re: hurd-i386 updates
On Tue, Jul 13, 2004 at 12:26:12AM -0500, Branden Robinson wrote:
>125 static void
>126 xf86PrintOSKernelString(void)
>127 {
>140 if ((infile = fopen("/proc/version", "r")) != NULL)
Doesn't look much different from `uname -srv`. We could use this hack for
Linux and a simple uname() call otherwise.
But I don't see why this requires a macro in the conffile. Can't we just use
#ifdef __linux__ in the code?
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T., Ainulindale (Silmarillion)
Re: hurd-i386 updates
On Mon, Jul 12, 2004 at 01:55:33PM -0600, Joel Baker wrote: > > I think this was the general direction you were going anyway, but wanted to > point out that Robert's k*BSD.cf (Glibc-based) [...] Actualy, my k*BSD.cf files only contain kernel stuff. The Glibc-based GNU/k*BSD ports use gnu.cf directly (as Glibc systems this works fine). Now that Michael has overhauled gnu.cf, my idea is to merge the (minor) k*BSD bits into a conditionalised section in gnu.cf, together with a bunch of conditionalised sections copied from linux.cf. This way we can get all Glibc-based ports to use the same base configuration. As for non-Glibc ports, we will have to split the Debian bits out of gnu.cf into, say, debian.cf. Then both gnu.cf and NetBSD.cf can use that. What do you people think? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion)
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 KernelVersionInBannerYES > > > > 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
Re: hurd-i386 updates
On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote:
> Hello,
>
> I've brought the hurd-i386 port of xfree86 back on track.
Outstanding! Thank you!
> 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?
> The resulting packages are up at the ftp.gnuab.org repository and they
> work well on my Radeon7500 with the ati driver.
Cool.
> However, the k*BSD patches are pretty big and Robert Millan apparently
> wants to get them applied upstream, which seems works quite well. On the
> other hand, the hurd-i386 needs updated xfree86 packages on
> ftp.debian.org ASAP to continue the development effort. Thus, I've just
> updated the 80* series of patches to make xfree86 build and install on
> hurd-i386. The attached file xfree86_gnu_patches.diff contains those.
Okay.
> In order to have a clear look at the differences between linux.cf and
> gnu.cf, I shuffled gnu.cf around and reformatted some parts, in order to
> sync the two and make the diff somewhat easy to read.
Yes, that was badly needed. Thanks!
> The main questions are the following defines, which were missing in
> gnu.cf (diff from linux.cf to gnu.cf):
>
> -# define StaticNeedsPicForShared NO
> -# define KernelVersionInBannerYES
>
> 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.
I would #define StaticNeedsPicForShared NO for the Hurd, assuming your
packages are going to be pretty congruent with the Linux ones.
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.
Checking that file, we find the following:
69 #ifdef XF86_KERNEL_VER_IN_BANNER
70 static void xf86PrintOSKernelString(void);
71 #endif
[...]
122 #ifdef XF86_KERNEL_VER_IN_BANNER
123 /* The following function is an "ugly hack". mharris told me to say so.
*/
124 #define KVERMAXBUF 1024
125 static void
126 xf86PrintOSKernelString(void)
127 {
128int tainted = -1;
129char *buf;
130FILE *infile;
131
132if ((buf = (char *) calloc(1, KVERMAXBUF)) != NULL)
133{
134 if ((infile = fopen("/proc/sys/kernel/tainted", "r")) != NULL)
135 {
136 fgets(buf, KVERMAXBUF, infile);
137 fclose(infile);
138 tainted = atoi(buf);
139 }
140 if ((infile = fopen("/proc/version", "r")) != NULL)
141 {
142 if (fgets(buf, KVERMAXBUF, infile) == NULL)
143 sprintf(buf, "(unable to determine)");
144 else
145 buf[strlen(buf) - 1] = '\0';
146 fclose(infile);
147}
148}
149ErrorF("OS Kernel: %s %s%s\n", buf, (tainted & 0x01) ? "T" : "",
150(tainted & 0x02) ? "F" : "");
151free(buf);
152 }
153 #endif
[...]
1690 static void
1691 xf86PrintBanner()
1692 {
[...]
1741 #ifdef XF86_KERNEL_VER_IN_BANNER
1742xf86PrintOSKernelString();
1743 #endif
1744 }
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.
(Why this function isn't in xc/programs/Xserver/hw/xfree86/os-support
someplace instead of having Linux-specific code bolted into the "common"
directory, I'm not sure. Probably laziness and/or sloppiness.)
> -# define BuildRenderLibrary NO
> -# define HasRenderLibrary YES
> -# define BuildXcursorLibrary NO
> -# define HasXcursorLibraryYES
> -#ifndef HasLibpng
> -#define HasLibpngYES
> -#ifndef HasGroff
> -#define HasGroff YES
>
> As hurd-i386 has those libraries/programs now, I added those.
Sounds rig
Re: hurd-i386 updates
On Mon, Jul 12, 2004 at 08:40:25PM +0200, Robert Millan wrote: > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > Hello, > > > > I've brought the hurd-i386 port of xfree86 back on track. > > [...] > > > > In order to have a clear look at the differences between linux.cf and > > gnu.cf, I shuffled gnu.cf around and reformatted some parts, in order to > > sync the two and make the diff somewhat easy to read. > > Very nice! Now that gnu.cf is overhauled and the differences with linux.cf are > minimal, what would you think of merging linux.cf into it? > > We could have some #ifdef'ed snippets of kernel-specific macros in gnu.cf, > but most of it would be generic. This way we can get Debian GNU/Linux ports > to switch to gnu.cf and we don't need to maintain separate files. I would > also like to add the k*BSD definitions that used to be in k*BSD.cf and > included from gnu.cf (in my unmerged patches). > > I can add these to your patch, make sure that nothing breaks on GNU/Linux, > and commit it. Sounds ok to you? For the record (and not that I think this should stop anything), the NetBSD (Nienna) build is derived largely from gnu.cf, and thus may need to be redone after this. Conversely, I had to sort out a lot of the same things and figure out what was the same, or different, based on 'GNU userland' vs. 'GNU core' bits, and having gnu.cf and linux.cf sanely comparable makes sense. The one thing I'd wonder (and I *haven't* looked at whether this is sane) is whether it would be possible to split the 'Debian' pieces (what userland apps are available, where manpages belong, etc) from the 'core' pieces that are Linux/Hurd/NetBSD determined. Otherwise we end up duplicating a lot of info between the three... I think this was the general direction you were going anyway, but wanted to point out that Robert's k*BSD.cf (Glibc-based) and the Nienna set (NetBSD libc based) have some very different choices for certain options - and a huge set of similarities to the current GNU, Linux, etc, files as Debian patches them. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpW6zAp2nMup.pgp Description: PGP signature
Re: hurd-i386 updates
On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > Hello, > > I've brought the hurd-i386 port of xfree86 back on track. > [...] > > In order to have a clear look at the differences between linux.cf and > gnu.cf, I shuffled gnu.cf around and reformatted some parts, in order to > sync the two and make the diff somewhat easy to read. Very nice! Now that gnu.cf is overhauled and the differences with linux.cf are minimal, what would you think of merging linux.cf into it? We could have some #ifdef'ed snippets of kernel-specific macros in gnu.cf, but most of it would be generic. This way we can get Debian GNU/Linux ports to switch to gnu.cf and we don't need to maintain separate files. I would also like to add the k*BSD definitions that used to be in k*BSD.cf and included from gnu.cf (in my unmerged patches). I can add these to your patch, make sure that nothing breaks on GNU/Linux, and commit it. Sounds ok to you? -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion)
