Hurd Traffic #94 For 14 Jun 2001

Editor: Zack Brown

By Paul Emsley

Mach 4 ( | Hurd Servers ( | Debian Hurd Home ( | Debian Hurd FAQ ( | debian-hurd List Archives ( | bug-hurd List Archives ( | help-hurd List Archive ( | Hurd Reference Manual ( | Hurd Installation Guide ( | Cross-Compiling GNUMach ( | Hurd Hardware Compatibility Guide (

Table Of Contents


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. (


1. ldconfig And Shared Libraries
31 May 2001 - 3 Jun 2001 (7 posts) Archive Link: "mandate ldconfig -X?"
Summary By Paul Emsley
People: Robert BihlmeyerMarcus BrinkmannBrian May

In a thread shared with debian-policy, Robert Bihlmeyer proposed

.. that instead of calling "ldconfig", maintainer scripts of packages containing shared libraries should call "ldconfig -X".


ldconfig has two purposes:

  1. For each shared library, create/update a symbolic link from the library's soname to the library file. The link is only changed if it was broken/non-existing before, or the library in question has a higher version than the current destination of the link.
  2. Update the locations of shared libraries in /etc/ Per default, ldconfig will execute both actions.


On a Debian system, the first point is moot, because library packages will include the appropriate symlink already as per policy.

The second action is generally useful. "ldconfig -X" will do just that, and omit the first.

Why should we not commit the first action anyway?

For one, it is unnecessary, and wastes time. But more importantly, the Hurd has no, which kills reason 2 on this platform. Debian GNU/Hurd systems also don't have reason 1, so there is currently no real ldconfig program on the Hurd. Rather than writing a program that's completely pointless, I'd rather we called ldconfig correcly, i.e. with the -X parameter. "ldconfig -X" will just do nothing on the Hurd.

Brian May asked what was wrong with the curent practice where ldconfig is a "do-nothing" program.

Marcus Brinkmann said that sometimes debian/rules scripts use ldconfig to set links. With the Hurd, there needs to be a dummy script which errors on unsupported operations and succeeds silently for unnecessary operations (such as rebuilding the cache). Marcus added:

If "ldconfig" is called in package scripts, we can not make the dummy script behave reliably: failing on what is not supported but should have an effect, succeeding on what is without effect on the Hurd.

It will also help to catch bugs in library packages on Linux, because missing links won't be created automatically, out of dpkg's control. Although I think that lintian has a check for it.

To summarize, it will help us catch abuses (incompatible uses) of ldconfig in scripts and package builds, so we don't succeed silently although we didn't perform the requested operation.

But beside helping the Hurd, it will also help everyone by making our software better and more more transparent (it is more clear what the intention of calling ldconfig is).

Brian seemed to have trouble getting his head round the problem: "Are you saying ldconfig can't update the links on Hurd? Can this be fixed?"

Robert replied "Sure. It ain't broke, though." . Bug #83669 ( (or the solution to it, commented on by Ian Jackson and others) gave Brian cause for concern.

Marcus replied:

[bug #83669] is targeted at making it possible to compile packages for stable on a system running mostly software from unstable. I think it is ill-advised to implement this functionality in Debian. If you just need a few packages, you can compile them yourself from source. If you do it on mass, you should have a stable chroot, or a seperate machine for it.

To answer your question, this conflicts directly with what we expect for the Hurd. But if it is necessary, we'll have to deal with it by providing an ldconfig that creates symlinks. It would be a Debian specific hack, as the Hurd itself does not require this (and we don't want it either).

I think it would not be to Debians advantage to allow [installing multiple libraries at the same time (if the major number is the same, but the minor number is different)]. It's much easier for us if IanJ or whoever wants to build for old libraries exploits one of the many possible existing alternative solutions for his problem (building on a stable machine, in a chroot, install older libraries in some other tree and compile against them, etc etc).

Roberts proposal and the proposal derived from IanJs conflict. However, if not ldconfig were used to install those library links described in #83669, but some different mechanism (update-alternatives, for examples), both proposals can be implemented easily. Otherwise, if #83669 is implemented, we will have to cope by providing an ldconfig on the Hurd that creates missing symlinks.

The situation seems unresolved at the moment.


2. Debugging (Guile), Get/Install Source
2 Jun 2001 - 7 Jun 2001 (7 posts) Archive Link: "dynamic-linking"
Summary By Paul Emsley
Topics: Apt
People: Marcus BrinkmannPaul Emsley

Paul Emsley asked if there was a reason why (dynamic-link "./") might fail. Marcus Brinkmann said that there were lots of potenial reasons. He suggested:

Compile guile with debugging symbols, install libc0.2-dbg and run

LD_LIBRARY_PATH=/lib/debug:/usr/X11R6/lib guile your-program

when it hangs, attach gdb to it. I think you need to give it the same LD_LIBRARY_PATH. Find out the process id of guile and do

LD_LIBRARY_PATH=/lib/debug:/usr/X11R6/lib gdb guile PID

then get a backtrace and see where it hangs. If you can't make any sense out of it, run gdb in a "script" session and send us the transcript of "bt full", and "info regs", maybe even the disassembled code at the PC (forgot the command).

Paul did this and when Marcus saw the debugging log, said "The dynamic linking seems to be handled in scm_dynamik_link, with the meat of it (the os dependant part) in sysdep_dynl_link. Then there seem to be some more layers in guile responsible to wrap up the dlopen call in frame #12. From there on it's glibc. So we can safely say it is a glibc bug. In fact, after some digging in the ChangeLogs and poking around in the glibc source tree, we find in sysdeps/mach/bits/libc-lock.h [some libc recusive lock defines]. Because cthreads does not support recursive locks, and we need one here (see elf/rtld.c, _dl_load_lock), we get a dead lock. In other words, loading shared objects at run time doesn't seem to be supported (very well? at all?). "

Paul also has a problem with apt-get source core dumping. To this, Marcus replied:

If apt doesn't work, you have to go to and fetch the most recent dsc, orig.tar.gz and diff.gz (if any) manually. Then you can do:

dpkg-source -x guile*dsc

to extarct the source. (Make sure you have dpkg-dev installed).


3. Shared Libraries Over NFS, Rpctrace
2 Jun 2001 - 3 Jun 2001 (14 posts) Archive Link: "interesting ORBit behavior"
Summary By Paul Emsley
Topics: FS: NFS
People: Nick RusnovRoland McGrathPaul Emsley

Nick Rusnov had been experimenting with CORBA and translators, but had a problem:

when you first compile the test program (which reads a number from random,org's corba interface and prints it out), exactly every other time it dies, saying only 'Killed'. I suspect it never gets into main, somehow, because I interleved all the CORBA statements with puts, and none of them are reached (I made the io unbuffered afaik, so it should print out at least the first few statements before dying).

Things get interesting when you run it under gdb, it works every time. After you exit gdb it appears to run every time also.

It runs every time under rpctrace, but doesn't actually make the CORBA call (it ruturns 0).

It seems that this is the sort of problem to interest Roland McGrath, "How exciting!" he said.

At least it sounds like it is a consistent pattern so you can readily make it crash again. Can you also try ldd on your binary and see if that works consistently or has any correlation to the crashes you see?

Your test program doesn't print anything immediately on entry to main. You should certainly do that. I don't know what all happens in "CORBA_exception_init", but that may well be where it's crashing. If it always makes it into main, then it is probably not a generic dynamic linker problem (which is often a suspect for this kind of crash). Also try setting LD_BIND_NOW=1 in the environment and see if that changes the behavior.

There followed some discussion and confusion about shared libraries, until Roland asked: "Are you using NFS?" Nick tried without using NFS and reported back: "It was NFS. DOH. Outside of NFS, I can't get it to 'Killed'. " Paul Emsley chipped in saying that he had also seen Error 1073741869 (which is EOPNOTSUPP). Roland said "The specific problem issue is shared libraries that reside on NFS filesystems."

The conversation progressed onto examining why the translator did not work. Nick was using "less" to examine the translator results, but Roland advised him to stick to something simpler such as "cat".

Roland looked at the rpctrace log and said:

That output looks like it's from an older version of rpctrace. The output from the current rpctrace is a bit better organized (though still quite cryptic to most people). rpctrace lives in one file that is easily compiled outside of the hurd source tree; you can just grab utils/rpctrace.c from the sources and compile it:

cc -D_GNU_SOURCE -g -o rpctrace rpctrace.c -lports -lihash -lthreads

Several people have expressed interest in improving rpctrace, but noone has actually done anything about it. You have already found your own motivation for wanting better output from rpctrace, so perhaps you would like to work on that? The first thing it needs to start being comprehensible is to output RPC names instead of raw msgid numbers. Understanding the rpctrace output is one of the best ways to understand the fundamental architecture of the Hurd.

I certainly encourage you to improve rpctrace and learn about your translator's problems that way. That work will help a lot of other people in the future as well. But to just debug your translator per se, you can simply attach gdb to it and go to town.


4. Documentation, Binary API Compatibility
3 Jun 2001 - 5 Jun 2001 (11 posts) Archive Link: "and now ?"
Summary By Paul Emsley

karim ben djedidia installed GNU/Hurd and asked about documentation and binary compatibility between GNU/Hurd and GNU/Linux. He was pointed to documentation in ( ) and There was some discussion about binary compatibility, Neils Möller said that the plan was to have glibc ABI the same, so the executables linked purely with shared object libraries and without making direct kernel syscals will work on both systems. Marcus added that pthreads and using libio in glibc are the substantial steps yets to be taken.


5. Big glibc Cause Problems
3 Jun 2001 - 5 Jun 2001 (7 posts) Archive Link: "Partition size and glibc build"
Summary By Paul Emsley
Topics: FS: NFS
People: Neil WalfieldJeff BaileyRobert BihlmeyerOystein Viggen

Jeff Bailey compiles glibc. However, now the glibc package is larger than 981Mb. He wanted to know the absolute maximum for the current native Hurd partition size. Jeff was deliberately avoiding building over NFS because of the pfinet problem. Oystein Viggen suggested splitting between several filesystems. Robert Bihlmeyer asked about the correct wasy to cross-compile glibc. Jeff replied:

dpkg-buildpackage -ahurd-i386 -B -rfakeroot

Neil Walfield replied that the gcc-i386-gnu package should take care of cross-compiling (but that he had not tried it recently).


6. Problems Booting With Plex86
5 Jun 2001 - 6 Jun 2001 (5 posts) Archive Link: "gnumach & plex86"
Summary By Paul Emsley
Topics: Bootloaders, Emulators: plex86
People: Igor KhavkineMarcus BrinkmannRoland McGrath

Igor Khavkine asked Marcus Brinkmann "Just how fast is plex86 on your machine? Last time I tried it (a couple of weeks ago) it was extreeeeeeemly slow. It took 30 seconds just to draw the GRUB menu." Marcus replied that it is drawn in a second or so, "A full boot with crash takes two or three minutes or so" he added.

Igor also asked "Right now I'm trying to set it up so I could comunicate with it through the serial port. BTW, does anyone have suggestions for serial line communication programs other then minicom and `cat >/dev/ttyS1' and `cat /dev/ttyS1' in two different xterms? " Roland McGrath replied "I have always used the vanilla `cu' and `tip' programs (I don't think current Linux systems have `tip', but `cu' is part of GNU/Taylor UUCP)." Eduardo Ochs suggested using "expect".


7. Interupt Fails In Single-User Mode
5 Jun 2001 (2 posts) Archive Link: "interrupting a process at console"
Summary By Paul Emsley
People: Jeff Bailey

After he has installed GNU/Hurd, "Ian" commented on the difficulty of interupting and suspending processes. Jeff Bailey replied that that is a known problem in single user mode. "Reboot without the -s after the gnumach line," he advised.


8. Easy Guide Feedback
5 Jun 2001 - 6 Jun 2001 (8 posts) Archive Link: "Easy Guide feedback"
Summary By Paul Emsley
People: Matthew VernonPaul EmsleyJim Franklin

Matthew Vernon asked for feedback on his Easy Guide ( . He got a couple of positive responses and Jim Franklin advised him to update one of his links.

(ed. [Paul Emsley] It seems to me that the focus of document is now somewat dated since we now can install from CD (more information about partition names cannot be faulted however). ( )


9. FAT Support
6 Jun 2001 (2 posts) Archive Link: "FAT Support"
Summary By Paul Emsley
Topics: FS: FAT, FS: ext2
People: Marcus Brinkmann

Thomas Langan asked about the status of FAT support and asked how long it would take to implement. Marcus Brinkmann replied:

It took me the ext2fs and ufs example server code, the M$ standard about FAT filesystems and the better of three days to get a read-only implementation.

The FAT format is not the problem, although I left some loose ends you are welcome to clean up (like character tabes, long file name support etc). Organization of the metadata is. (The lack of inodes in FAT is contributing to the problem). It is unlikely that your library is matching the semantics of the Hurd libdiskfs, so you could probably hack up an essentially single threaded server only.


10. getsockopt() Was Broken
6 May 2001 - 6 Jun 2001 (6 posts) Archive Link: "getsockopt() hurd/glibc mismatch"
Summary By Paul Emsley
People: Marcus BrinkmannRoland McGrathRobert Bihlmeyer

Robert Bihlmeyer had been struggling trying to get ssh working. He said that getsockopt(socket, SOL_IP, IP_something, &option) was returning garbage with the Hurd. Robert and Marcus Brinkmann discussed IP defines. Marcus said "I suggest you step through pfinet for the getsockopt call. You can debug translators just like other programs (set breakpoints, step through). " Some time later Robert got round to doing just this and found the problem was indeed with getsockopt (in glibc). He proposed proposed a fix which Roland McGrath added to glibc.







We Hope You Enjoy Hurd Traffic

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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.