Hurd Traffic #93 For 11 Jun 2001

Editor: Zack Brown

By Paul Emsley

Mach 4 (http://www.cs.utah.edu/projects/flux/mach4/html/) | Hurd Servers (http://www.gnu.org/software/hurd/hurd.html) | Debian Hurd Home (http://www.gnu.org/software/hurd/debian-gnu-hurd.html) | Debian Hurd FAQ (http://www.debian.org/ports/hurd/hurd-faq) | debian-hurd List Archives (http://lists.debian.org/#debian-hurd) | bug-hurd List Archives (http://mail.gnu.org/pipermail/bug-hurd/) | help-hurd List Archive (http://mail.gnu.org/pipermail/help-hurd/) | Hurd Reference Manual (http://www.gnu.org/software/hurd/reference-manual.html) | Hurd Installation Guide (http://pick.sel.cam.ac.uk/~mcv21/hurd.html) | Cross-Compiling GNUMach (http://pages.hotbot.com/sf/igorkh/gnumach-cross.txt) | Hurd Hardware Compatibility Guide (http://www.urbanophile.com/arenn/hacking/hurd/hurd-hardware.html)

Table Of Contents

Introduction

Want to help write KC Debian Hurd? See the KC Authorship page (../author.html) the KC Debian Hurd homepage (index.html) , and the Thread Summary FAQ (../summaryfaq.html) . Send any questions to the KCDevel mailing list. (mailto:kcdevel@zork.net)

1. Autoconf And The Hurd

27 May 2001 - 28 May 2001 (13 posts) Archive Link: "Hurd's configure.in"

Summary By Paul Emsley

People: Igor KhavkineNiels MöllerRoland McGrathThomas Bushnell

Igor Khavkine wrote:

I just pulled the Hurd souces from CVS and tried to build it. However I ran into a problem right away. When trying to generate a configure script with the command `aclocal; autoconf' I get these errors:

configure:1336: error: possibly undefined macro: AC_PROG_CC_GNU
configure:1313: error: possibly undefined macro: AC_TRY_COMPILER

Niels Möller noted that "you should not be running aclocal. aclocal is part of automake, not autoconf. For non-automake projects, aclocal.m4 is written by hand and checked into cvs"

Roland McGrath replied that configure.in works fine with autoconf-2.13.

Later Igor added "I think I have a handle on the situation. It does work with autoconf-2.13 but not 2.50 which is the one in unstable right now. Turns out that the macros that were giving me errors no longer exist and must be replaced. After some struggle with autoconf and its documentation, I came up with a patch which seems to fix things. "

Later still, Igor added: " the macros defined below still use AC_PROG_CC_GNU and AC_TRY_COMPILER have ceased to exist somewhere in between the versions 2.13 and 2.50 of autoconf. "

Roland replied: "then it's the case that autoconf-2.50 is incompatible with current libc also. Why don't you report that to bug-glibc? I'll wait to see how it's resolved in libc and then do the same for hurd and gnumach."

Igor send a message to bug-glibc and said:

there is a huge discussion of the autoconf upgrade on the debian-devel list. The discussion mostly centers about how to deal with packages that break with the new autoconf, from the package maintainer's point of view. I suggest that we take the developer's point of view and elect to fix the problem upstream with updated aclocal.m4 and *.in files.

I'm currently reading autobook, to familiarize myself with the autotools build chain. I've noticed a harsh lack of autoconf gurus around, so I'm going to try becoming one myself.

However, Thomas Bushnell was not impressed: "The discussion there is totally broken; Debian developers should not be running autoconf at all in the normal case. GNU packages come with configure scripts, and those scripts Just Work, whether you have whatever version of autoconf installed or none. "

2. gcc 3.0

29 May 2001 (2 posts) Archive Link: "gcc-3.0"

Summary By Paul Emsley

People: Jeff BaileyRoland McGrath

Jeff Bailey said:

I have made my first attempt at compiling the gcc-3.0 snapshot. I am interested in persuing this because I'd like to see us switch to the new C++ ABI before we port many of the C++ packages.

Some of the other arch's are already using it, and we're very close to release. Ben's been encouraging people to make sure their software runs so I don't think it will be a bad thing.

Are you willing to consider this?

Roland McGrath replied: "I leave it to Marcus to decide which GCC version we want to use in general. But it certainly seems like a good thing to do all the testing you mentioned with the new GCC and fix the bugs that come up. [With reguard to bug reports:] use your judgment. For any Hurd-specific issue, we want to consider it here before deciding on what to tell the GCC folks is the right solution for the Hurd. But e.g. if the compiler crashes, then there's no need to filter than through us before reporting it as a GCC bug. "

3. Keymaps, Kernel Hacking

24 May 2001 - 28 May 2001 (4 posts) Archive Link: "Q: Problem with the keyboard (not under X) and other questions"

Summary By Paul Emsley

People: Marcus BrinkmannBertrand Sirodot

In response to questions from Bertrand Sirodot about keymaps, kernel drivers and the status of mach, Marcus Brinkmann replied: "

console-tools is linux specific software. Although it makes sense to reuse their data files and share them, there is currently no application to make use of them on the Hurd. I hacked together a simple replacement a long time ago, which you can find in ftp://alpha.gnu.org/gnu/hurd/contrib/marcus/keymap.tar.gz

The Hurd servers are implemented entirely differently from monolithical kernel filesystems. BTW, kernels like linux already have a virtual file system layer where filesystems plugin. But you have to look at a different place to find out how this works.

You will only find GNU Mach in the binary archive. If you want to do kernel hacking, use oskit-mach.

"

4. More on Openssh

25 May 2001 - 29 May 2001 (7 posts) Archive Link: "openssh on hurd"

Summary By Paul Emsley

People: Robert Bihlmeyer

Following on from last week's thread Robert Bihlmeyer posted the location of the openssh daemon that he had built (http://pluto.tuwien.ac.at/~robbe/debian/hurd/) , but warned "these do not (always) work on the newest Hurd (the problem is with IP options)."

5. OSKit-Mach Sources

29 May 2001 (2 posts) Archive Link: "OSKit-Mach sources"

Summary By Paul Emsley

People: Bertrand SirodotOgnyan KulevRoland McGrath

Bertrand Sirodot "asked what is the current status of The Hurd on OSKit-mach? Where can I find the sources of the OSKit-mach kernel? "

Ognyan Kulev replied:

There is a temporary page for GNU Mach (and oskit-mach): http://debian.fmi.uni-sofia.bg/~ogi/hurd/hurd.gnu.org/gnumach.html. The status is not changed from what Roland McGrath said. There is information how to get and build oskit-mach.

I'll appreciate any comments and bug fixes in this paper. It will disappear till a week and will be included in the new http://hurd.gnu.org in separate pages.

6. MAXHOSTNAMELEN Definition And POSIX Compliance

23 May 2001 - 2 Jun 2001 (16 posts) Archive Link: "Another package ported"

Summary By Paul Emsley

Topics: POSIX

People: Igor KhavkineThomas BushnellMarcus BrinkmannJim FranklinRoland McGrathJeff BaileyPaul Emsley

Igor Khavkine reported that that he had ported bsdgames.

Now it can be added to autobuilder (this part is for you Jeff). The patch is available from my site http://alcor.concordia.ca/~i_khavki/ and I will submit a bug report.

The only changes were the standard MAX*LEN problems. In the case of MAXHOSTNAMELEN, I just defined it to 256 following SUSv2. Even though the standard does not define this macro, it does say that hostnames can't be longer then 256 characters.

Since there seemed to be a standard for a maximum hosthame length, Igor, Jeff Bailey, Roland McGrath and Marcus Brinkmann then discussed the addition of the definition of MAXHOSTNAMELEN into the Hurd headers.

However, Thomas Bushnell had other ideas: "Blech blech blech blech. Argh. I don't want there to be a max. "

Marcus came to the rescue:

Nevermind, the standard is a moving target. What I quoted was from draft 5, and I now checked draft 6, and it does not refer to a single constant "255" anymore. [I am talking about the POSIX draft as currently developed by the Austin Common Standards Revision Group (www.opengroup.org/austin)] Instead, it refers to HOST_NAME_MAX, which has the minimum acceptable value 255, but may be unspecified. So, the situation will be just as with PATH_MAX.

It's not a standard yet, but it seems it will replace the various UNIX standards (1003.1/96, 1003.2/92 and the core of SUS).

The thread was continued somewhat in help-hurd under the title POSIX compliance (http://mail.gnu.org/pipermail/help-hurd/2001-May/004599.html) . Jim Franklin asked:

Is there a reason we follow the standard at all times? If the hurd is cutting edge technology wouldn't it seem that the standard should to some extent conform to the hurd's requirements? Is there a particular benefit to being completely POSIX compliant? Are there ways to petition the POSIX standards committee to modify their standard in certain instances?

I guess what I'm trying to say is if the hurd is GNU 'GNU is not Unix', why would the hurd try so hard to be Un*x standards compliant. Wouldn't it be better to try to be POSIX compliant where ever possible but where it hinders developement of the hurd either document the change to POSIX compliance in the code or ask for a change in the standards from the folks who write the POSIX standards?

Thomas replied that they (presumably the FSF and/or GNU) "have very little power in the standards process. We used to have more, but we stopped bothering. "

He went to to say:

But the real point is that we want to be able to run arbitrary programs on our system. It's not like we must have approval from some agency, and there might come a point where we have to say "this sucks, it's a no-go".

The particular case of MAXHOSTNAMLEN is not such a case: the Posix standards committee (and its friends) is not the problem. The DNS imposes host name limitations in various ways, and so do other parts of internet architecture. So it sucks that we have to have the limitation repeated in the Hurd.

Changing the subject somewhat Paul Emsley quoted Olin Shivers and asked about the state of compliance of the Unix exec(2) syscall.

Thomas replied:

With regard to multiple arguments, we are forced to implement the Unix lossage here in order to preserve compatibility.

However, we do not have a line length limit.

I think we are perfectly able to handle #! recursion, though it would be useful if someone could check.

As for accurate error reporting, there's not much more you can do than return ENOENT or ENOEXEC or some such code. Alas, those are the perils of Unixoid interfaces.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.