Re: CrossTool

[Dan Kegel <dank at kegel dot com>]

Kristoffer Ericson wrote:
> Greetings Dan,
>
> Havent found a good mailinglist for crosstool (crossgcc?) so writing to you
> directly.

crossgcc's the right one, so I'm cc'ing my reply there.

> (using lastest crosstools version 0.37 i believe)
>
> I'm building a cross environemt to more easily develope for SH3 & Arm targets
> (Jornada6xx & Jornada7xx). I've used OpenEmbedded & Scratchbox before but found
> them to each lack things i desire. My basic idea is this :
>
> CrossEnvironment
> ----------------
> * All build (i686) binaries are static (bash,flex,bison,make,....)
> * host GCC (i686->SH3)is static & build GCC (i686->i686) is static
> * All libs are targetted at the target environemt (in this case SH3)
>  (there arent any i686 libs in the environment, so everything gets linked
> against the sh3 ones automaticly)
> * Letting a (SH3) CONFIG_SITE file handle all the configure issues.
> Chrooting into the environment and ready to go.

So you're really still looking for a scratchbox-like environment
where you can build things without really thinking about
the fact that you're cross-compiling.  Fair enough.
(BTW I hadn't heard of CONFIG_SITE; that's a good idea.
See http://groups-beta.google.com/group/gnu.utils.bug/msg/477826ef12505920)

> I use the host GCC as gcc,ld... and the build GCC as gcc-i686,ld-i686.
> In a dream situation i only need to go into a source directory, specifying :
> CONFIG_SITE=/....sitefile ./configure host=sh3-unknown-linux-gnu build=i686
> and the source compiles.
>
> My questions are these:
> 1. Would you consider this a resonable idea for the environment or is it better
> to just set the flags (CC,CC_FOR_BUILD,LDFLAGS..) in a script and use the
> standard sh3-unknown-linux-gnu-xxx?

CONFIG_SITE's a great idea; that's where you could set CC and all that.
The chroot is probably a good idea if you want to make darn sure
the packages don't get your build system's installed libraries
(though you'd have to make CC_FOR_BUILD be a self-cross installed
in a funny place to let it keep working).

> 2. I've encounterd issues when the configure script want to compile a test
> program and later run it (which of course fails due to it been compiled as a
> SH3 binary). I'm going to solve this by setting CC_FOR_BUILD to gcc-i686 when
> required.

That won't solve it.  Configure scripts that use AC_TRY_RUN are
really trying to probe the target.  There are several ways around this:
1) if the configure script is good, it will check the cache before
running AC_TRY_RUN, and you can override the test by setting an ac_foo
environment variable, perhaps inside SITE_CONFIG.  This works in many
cases, and is a standard technique.
2) if #1 doesn't work, you can patch the app to make #1 work :-)
and submit the patches upstream.  I've done this on several occasions.
It's good for the soul; everyone should do it a few times.
3) You could patch autoconf to make AC_TRY_RUN able to use a
remote shell; Paul Eggert, the maintainer of autoconf, has received
several of those patches.  You could request a copy of them from
him and test them for him.  This would give a scratchbox-like
experience without having to install scratchbox stuff.
And Paul and I, and everyone else, would thank you.

> 3. How can i change where the gcc (Sh3) expects to find its linker, libs..?
> I would want all my tools in the /bin /sbin /usr/bin and not need to link it
> against /opt/crosstool....

Why?  It's better to have them off in a corner where nobody
will find them accidentally.

> 4. Any good way to extract as many vars as possible into a config_site file?
>    Is there any major configure script that i could run on my jornada and then
>    dump the data?

Good question.  As a first cut, I would search for AC_TRY_RUN
in all the configure.ac scripts of the apps in question
and look at the AC_CACHE_VAL call they save the result with.
http://autoconf-archive.cryp.to/ac_func_snprintf.html
shows one example:

AC_CACHE_VAL(ac_cv_have_working_snprintf,
[AC_TRY_RUN(...

A little perl script could detect pairs of lines like that
and quickly learn all the cache variables one needs to know.

And another little perl script, given that list, could
easily check all the config.cache files left over from
a big build run (ideally on the target), and extract the values.


> Patches/diffs
> -------------
> I had issues setting up the sh3 toolchain as a static one and found that more
> was required other than setting the GCC_EXTRA_CONFIG, BINUTILS_EXTRA_CONFIG.
> Has this been solved or do you want me to send you the diff?

Others have described what needs doing, but another diff is
always welcome.  Send it to the crossgcc list.

> I'm not sure if I told you this before but the SH3 toolchain is confirmed to
> work, so you could make a note of it in the demo-sh3.sh file.

I mostly note that kind of info in buildlogs/index.html now.

> Due to the fact (know i said this before) that the sh3 toolchain target requires
> glibc > 2.3.4 in order to create working dynamic linked binaries, you should
> change the default to use atleast 2.3.4. (i've used gcc 3.4.4 with glibc
> 2.3.4).

That's a very good thing to know.

> Making a note in the demo-xxx.sh files howto make the binary static (remarked)
> would also be a good idea.

Or, better yet, in crosstool-howto.html... care to submit a patch?
I'm not into static tools, so I haven't paid much attention to them,
but I know some people want them.

Thanks!
- Dan

--
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

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