Re: relocating the compiler and associated tools

[Jim Tison <jtison at ntplx dot net>]

On Mon, 2004-11-08 at 16:34, Daniel Kegel wrote:
<snip>
> Yup.  Sadly, there is.   I have run into trouble doing what you're
> suggesting, so I don't try any more.  This may have been with
> an old gcc, but I have a bad feeling it was actually with
> a recent one.
<snip>
> For gcc-3.3 and later, there probably aren't many bugs left
> that would keep you from just moving the result.   If you're
> building a recent version of gcc, you might want to just try
> it and see what happens.   In the worst case, you could edit
> the installed binaries with a search-and-replace script; I've
> seen people do that.
> 
> Let us know how it goes.  Everybody would like this to work.
<snip>

In case I'm restating the obvious or what's already been said (I've only
been lurking on this list for about 3 years now), apologies. 

The only way I know of is to do the following in EVERY installed
directory (using crosstools or not), __INCLUDING__ your choice of r/t
library (glibc, newlib, uClib, etc, assuming you're moving those too): 

1. For all binary files: strings *
--> Look here for occurrences of your PREFIX & build paths. You know
what these are. You'll need to use some brute-force methods to change
these strings. More on this later.

2. For all text files (especially specs, and whatever you do, don't
forget those libtool convenience files!!): vi *
---> Again, look here for occurrences of your paths.

As an aid in these two steps, you might want to start by cd'ing into
your PREFIX directory, and then something like "find . -type f | xargs
file" just to get a handle on what's binary and what's text. This is a
great way to uncover those convenience libs that libtool leaves laying
around, too. 

If your target installation environment is NOT built around
/usr/<rest_here>, be on the lookout for "usr", too. System include paths
are definitely hard-coded into binaries.

When you build: 
a) Build into and install into RIDICULOUSLY long paths. 
b) Never EVER build into your source trees (but I'd hope we all
understand the wisdom of this).

When you move: 
--> KEEP THE TREE STRUCTURE. Some of the paths are relative.

For text files (like specs), the lengths of your working paths aren't a
problem: you can just change them with the editor of your choice.

For binary files, the lengths of your working paths can be a difficult
problem. Your brute force method (I like KHexEdit, others like vi in
conjunction with od, and I'm sure there are many more) has to replace
the destination path in the space allotted for the working path.
Obviously, this includes the terminating hex zeros at the end of each
string. If the space allocated is too short to hold the absolute paths
of the files in your final "move to" environment, you're dog meat.
Otherwise, just overwrite the old string at its beginning. Fortunately,
the C-style hex zero terminated string is used consistently.

The trouble with this method is that there is no guarantee on what's
going to work from release to release. Sometimes paths get compiled in,
sometimes they don't. All of a sudden, a new one will pop up (or an old
one will pop out) in release x+1. I don't see a way to script this
dependably.

If you're smart enough (most of us are) to figure out the purposes of
all the paths and files named in all the installed files, you can figure
out what to replace them with. You just HAVE to be consistent and
thorough. The good news is that most of the symlinks are all either
same-directory or relative-pathed.

You're also going to waste a lot of time: many times, these path names
to files are just the file names of the sources from which some of the
binaries were compiled. readelf helps a lot in identifying these -- if
you're using COFF or a.out variants, I can't help you. Compiling without
-g helps reduce the trash level.

On this note, if you're going to debug with a symbolic debugger, be sure
you do it BEFORE you move. Once you move the binaries, you'd need to
move the sources too. Bleh. Might as well strip all your executables
just before you move them, because any later debugging is out of the
question.

Dan, I've gotta respectfully disagree with you ... later versions of gcc
don't seem to be compiling in any less path information: if you miss a
string, you're gonna run into a weird bug sooner or later. 

The only real foolproof solution is to build to the intended true
destination. Symlink it if you must (if you can?). Like you, I've been
burnt with this so many times that I've just given up, and also like
you, I'd love this to work dependably.

I also liked the chroot jail idea. For some reason (like maybe I'm old
and my brain is brittle?), I'd never thought of that before. Will need
to mull that one over to see if there's a way to make that work
consistently -- can you really build like that without bootstrapping
from zero? What a neat way that would be to build embedded systems at
/usr (and other places you wouldn't consider on your build platform)!!

Peace,
--Jim--


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com