RE: another proposed crosstool project

["Dave Korn" <dave dot korn at artimi dot com>]

On 06 May 2007 17:23, Yann E. MORIN wrote:

> Dave,
> All,
> 
> On Sunday 06 May 2007 18:08, Dave Korn wrote:
>>   This entire build-headers stage is relevant only to Linux.  Please stop
>> confusing the issue!
> 
> Do you mean that if I build a cross-compiler targeting, say, cygwin, then I
> don't need any headers from the "cygwin OS" to build my tools?
> 
> How would glibc, for example, know the interface to this OS?

  Well, for a start, cygwin doesn't use glibc, it uses newlib.....
 
> Ditto for Slowaris, AIX, etc... I'd need at least the syscall table, no?
> Or am I missing something here?

  Ok: let me try to summarize.

  To build the cross-compiler, you need the standard headers and libs from the
target: that is, the headers that define the C standard library functions and
the libraries that implement them, along with the CRT startup .o files.  The
compiler, as you say, cannot know how to implement syscalls; it just emits a
function call to a function in the standard C library, and at runtime this
function is linked in and does the necessary syscall or whatever.

  In the simplest case, when you are cross-targeting an already-existing OS
with its own native compiler, you just take a copy of the 'include' and 'lib'
dirs from an installation of that OS, copy them somewhere convenient on your
build machine, and point the compiler's build process at it by using either
--with-sysroot or --with-headers and --with-libs.  During the cross-compiler's
configure stage, these headers and libs are copied into the include and lib
dirs in your cross-prefix ($prefix/$target/...), where the completed
cross-compiler will be able to find them and include/link them when
cross-compiling applications for the target.

  In the case of glibc or newlib targets, you can save yourself the trouble of
finding an existing installation to copy from by building the system library
from source as part of the overall cross-compiler build process.  To do this,
you first build a crude, cut-down, C-only version of the cross-compiler (aka a
"bootstrap" compiler); this can't build typical user-mode programs for the
cross target, as it has no runtime libs or startup files, but the library
itself doesn't require those (it is the source of them), so this cut-down
compiler lets you build the required system library and you can then install
it (which copies both libs and headers) into the cross-prefix.  You can then
successfully build the full cross-compiler.

  In the case of linux/glibc systems, even this simplistic 'bootstrap'
compiler needs access to a few of the kernel's system headers, and *that* is
the purpose of the "make headers_install" stage Robert is discussing.  By
taking a copy of the kernel sources, and running that command, you build and
install a set of the system headers that will be needed later on in the build
process.  These are not the user-level headers that will be required later
when you want to compile user-mode applications for that target; those are
provided by glibc.  These are very low-level headers that are required to
build glibc, which is highly target-dependent.
  

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
For unsubscribe information see http://sourceware.org/lists.html#faq