Re: Comparing Bill and Karim's cross-compile scripts. Updating Bill's to gcc 3.2.3.

[Karim Yaghmour <karim at opersys dot com>]

Hello Dan,

Dan Kegel wrote:
> I sat down and compared Bill Gatliff's script to the commands Karim
> gives in his book for building cross toolchains.
> The two are near-twins, although Karim doesn't present them as
> a script per se.

Interesting. I must admit that though I looked at almost a dozen different
build instructions, including Bill's instructions on how to build a
cross-development toolchain for the Dreamcast, I haven't looked at any
of the scripts out there, save for a rapid overview of the buildroot
scripts from Erik Andersen. The end result which I describe in the book
is very much a "best of breed" of what I already knew in addition to all
that I was able to find from other build instructions out there.

Lately, though, I was thinking about making a list of all available
scripts, and I came up with this (which, of course, includes Bill's
script):
http://www.embeddedtux.org/pipermail/etux/2003-May/000018.html

> Here are a few notes, with line numbers in Bill's script:
> 
> 214-216, 239-241: repeated code in Bill's, maybe nicer to hoist
> it out of the case.  Also, Bill doesn't copy asm-generic, but Karim does.
> (Is that important?  Possibly, if some arches use the generic include files
> instead of providing their own?  Which arches do that?)

The copying of asm-generic was added following a recommendation by Russell
King, maintainer of the Linux ARM port.

> 236: Karim specifies CROSS_COMPILE= when running kernel makes.
> This is probably a tad safer (say, when building on an iMac but
> targeting a strange ppc?)

The way I see it, and the way I tried to word it in the book, is that this
is really just good practice, because if you don't use CROSS_COMPILE=
all the time, you end up forgetting to use it when you need to. You can
skip it if you know what you're doing, as I suggest in the book.

> 286: in comment, Bill says --without-newlib when he means --with-newlib
> 
> 301-304, 328-331: repeated code in Bill's, maybe nicer to hoist
> it out of the case.
> Also, Bill passes --with-local-prefix=$(PREFIX)/$(TARGET) to gcc's
> configure, Karim doesn't.  Presumably that prevents searching
> /usr/local/include, which sounds important.
> http://www.ugcs.caltech.edu/info/gcc/install_3.html says
> "The default value for @option{--with-local-prefix} is `/usr/local' regardless of the value of
> @option{--prefix}."
> (But see also http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00197.html)
> 
> 367: Karim doesn't override AR or RANLIB.  That might be a problem on
> some architectures, causing bad manifests in .a files?

I haven't really found this to be a show-stopper in the cases I've
tested.

> 368: Karim specifies --prefix=/usr, but Bill specifies --prefix=$PREFIX.
> This means Bill's shared libraries have the wrong path hardcoded
> in them; you can tell using 'strings'.  e.g.
>    $ strings powerpc-linux/lib/ld-2.2.4.so | grep home
>    /home3/dank/h/powerpc-linux/lib/
>    /home3/dank/h/powerpc-linux/etc/ld.so.cache

Actually I found this the hard way. I used to put --prefix=$PREFIX,
just like most cross-setup tool instructions out there do,
but then I'd have to set LD_LIBRARY_PATH on the target, which sounded
odd. And sure enough, a few reviewers pointed out during the review that
a correctly build toolchain shouldn't need LD_LIBRARY_PATH=/lib. So I
scratched my head a little more, RTFM'ed, tried a couple of things, and
found that /usr is the only proper setting for --prefix here.

As for "--prefix=/usr" being a special case for Linux, this is straight
out of the GLIBC build instructions. In the "Specific advice for Linux
systems" section of the INSTALL file, it says:
"   Linux expects some components of the libc installation to be in
`/lib' and some in `/usr/lib'.  This is handled automatically if you
configure glibc with `--prefix=/usr'.  If you set some other prefix or
allow it to default to `/usr/local', then all the components are
installed there."

> 387: Karim overrides install_root=${TARGET_PEFIX},
> but Bill uses the default.  This is understandable given the
> difference in --prefix.  Karim's right, I think.
> Also, Karim gives prefix="", which I think is just his personal
> bias; I think it causes libraries to end up in /lib instead of
> /usr/lib on the target.

Actually, this just makes it so that all libs end up in
${TARGET_PREFIX}/lib on the host, which is fine for a cross-development
toolchain. On the target, though, this makes no difference since the
files that would usually be in /usr/lib are only useful at link time.
The libs you need to copy on the target for runtime would have to be in
/lib anyway.

> 388: Karim fixes up paths in ld.so, but Bill doesn't.
> Need to remove absolute paths from the ld.so in ${TARGET_PREFIX)/lib;
> maybe Bill just forgot to mention that?
> 
> 407: There's that whacky --with-local-prefix= again in Bill's, but not Karim's.
> 
> And of course, Karim's already got an addendum on how to get this
> stuff to work with gcc3.2.3.  Also, Bill has detailed fixups for
> specific problems with various platforms, whereas Karim only
> covers one architecture.

I have tried to keep the instructions identical in as much as possible
across all archs. There are some archs which require a few tricks,
that's true. In as far as a comparison is made between instructions,
however, I do cover all the *Linux* arch-specific tricks I can see in
Bill's script. Most notably, the -Dinhibit_libc hack for ARM is covered
in table 4-2 on p.111.

> Smash the two together and we have our holy grail of a Bill script updated to 3.2.3 :-)

As I point out in the above archived mail, I'm not personally a fan
of automated scripts, but I understand some people prefer using them.
That's perfectly fine too. Bill's input, like that of other reviewers,
has been critical in making this book, and I'm glad the end result
is helpful to those using his script.

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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