help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compiling glibc+hurd from cvs


From: Marcus Brinkmann
Subject: Re: compiling glibc+hurd from cvs
Date: Thu, 26 Feb 2004 15:33:03 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 25 Feb 2004 23:53:23 -0500,
Rian Hunter wrote:
> 
> Eh, i compiled the latest libc and hurd from cvs today, installed then
> rebooted

There is a brave man!  ;)

> and it would freeze on trying to start ext2fs.static.

I am not sure you can be positive about if it tries to start it or it
is already running and freezes while running it.

Now hopefully you did work on a copy of your installation.  Anyway,
it's a long time I did all this and my memory of potential problems is
long but vague.  First of all, take a working installation and try to
run "ext2fs.static" on that one.  You won't have any dynamic linker
issues as this is statically linked.  This will give you a first
indication.  It's not 100% correct (it can be successful although at
boot it won't work, and the other way round), but it's definitely one
of the first things I'd try.

Then you have to take a look at your installation, if everything is
sane.  Do you have a /servers/exec node (without a node like that,
ext2fs.static can't run).

Then look at the links in /lib.  In particular /lib/ld.so,
/lib/ld.so.1 and whatever there is must exist and be set properly.
Compare this with a working installation.

Try to replace only ext2fs.static on a working installation (don't
overwrite it, just give it a new name, ext2fs.static.new, and change
your GRUB script).

Try to replace only glibc.  That's harder, but worthwhile.  I really
recommend to build Debian packages even from CVS.  It's not too hard
to do, and you have a clean setup.

As ams said, you don't need to reboot to do any of that.  Setting up a
sub-hurd will allow you to play around with that.  Extrelemy
worthwhile.  Although not 100% stable, so give it some slack.

Then you can try running programs with LD_LIBRARY_PATH set and
specifying the linker explicitely.  Now, that is something that really
requires you to know a bit about glibc, its components, and how to
diagnosed problems.  It works something like this:

LD_LIBRARY_PATH=/glibc-test-install/lib /glibc-test-install/lib/ld.so.1 
MY-PROGRAM

However, that might only be a first approximation.  I don't do this
often enough to know it by heart.  Using the debug option to ld.so.1
will give you some indication which libraries are loaded.  If you do
it right, you can get the new glibc without installing it or booting
it in a subhurd.

Remember that the problem can potentially be everywhere, and be creative!

> have any clue why it just froze? I think it was maybe gcc-3.3 but i'm
> not sure. I'm sure these questions are asked a lot on the list, so if i

Trying gcc 3.2 is also worthwhile, however, it would just be a stab
into the dark without knowing where exactly it fails.

It just froze because it encountered a problem at a stage where it can
not report an error, or because the error is not even recognized as
such.  There are plenty of opportunities for this.

Thanks,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]