[pocket-linux] Chapter 3 root disk problems redux

[David Horton]

> -----Original Message-----
> From: Dominick Mancine [mailto:dmancine at gmail.com]
> Sent: Tuesday, February 8, 2005 05:48 PM
> To: pocket-linux at ufo.chicago.il.us
> Subject: [pocket-linux] Chapter 3 root disk problems redux
> 
> Firstly, thanks for this guide, which is such a great idea.  Another
> great resource is the From Power Up to Bash Prompt guide, for those
> who want to read even more.
> 
> I posted the message below to the troubleshooting forum, but noticed
> that for about 10 questions there, there were only 7 replies.  Thought
> the mailing list would be more help.
> 
> So I browsed the list archives and found out my problem (no bash
> prompt when using dynamically-linked libraries) is pretty common,
> especially because I'm developing on RH9 on an AMD 900MHz machine, but
> running on a Pentium 100 with 32MB memory.  So, I'll abandon my
> original question and replace it with some other ones I came up with.
> 
> The consensus on the list seems to be that this is caused by libraries
> not being able to run on older hardware.  When I statically link bash,
> I get the shell prompt.  It should be using the same version of the
> library to link with (though it uses the .a file, not the .so,
> right?).  My first question is this:  How come bash can run with the
> static version of the libraries, but can't run with the dynamic
> versions?  It's the same code, just packaged different, right?  Or am
> I missing something?  (Okay, that was 3 questions.)
> 
> I'm not a Linux guru, yet.  If the gurus on this list say that that's
> the way the world works, I'll accept it.  But, I don't want to have to
> accept that I have to download the root disk image for chapter 3 to
> make things work (btw, this *did* work).  So, my other question is
> this:  Is there a procedure to force the libraries to work when
> dynamically linked?  A recommended development/testing system?  A
> requirement for the test box, relative to the dev box (like, same
> processor)?  Or, even better, a way to build the required libraries
> for the target machine?
> 
> This seems to be a pretty popular problem, because having separate
> development and target machines is oh-so convenient, and we don't mind
> messing up an old machine by booting an experimental OS.  Could there
> be a section added to the guide to address this issue?  Or at least a
> heads-up, with a pointer to the mailing list archives?
> 
> Sorry for the rambling, but I don't think the answers to these
> questions were in the archives.  I apologize for reasking the
> questions if they were.
> 
> Dominick
> 
> 

Dominick,

As far as I know the standard Redhat libraries are optimized for i686 and up.  I'm pretty sure that there are i386 libraries that get installed too, but my guess is that they are not used if a high-end processor is detected during the initial install.  So why does static-linking work?  Good question.  I'm guessing it has something to do with the way the linker is set up on RH, but I am not enough of a Redhat guru to know for sure.

Now, about fixing it without resorting to a prebuilt diskette image.  You can do a couple things.

1) Download the pre-compiled glibc package from: http://www.happy-monkey.net/architect/bin-pkgs/ and pull out what you need.

2) Build your own libraries from source.  It takes some time to compile (a couple hours on my P-III 550 w/512M RAM), but it really is not any more difficult than building any other package.  There is are build scripts that can help you out at: http://www.happy-monkey.net/architect/blueprints/package/i386/


Good Luck,
Dave