native builds

Tue Mar 3 22:52:00 GMT 2009

Roland,
All,

On Friday 27 February 2009 20:00:31 Roland Schwarz wrote:
> Yann E. MORIN wrote:
> > What are you refering to by "running on the same host"?
> > Are you saying the _compilers_ are to run on the same machine?
> > Or do you mean that the compilers should _produce_ code that run on the
> > same machine?
> The compiler shall (be able to) run on the same machine for which it is
> producing code.

I'd rather say the opposite: "the compilers should be able to generate
code for the same machine they are running on".

> The biaries just should be linked to a different glibc. 
> (Does this make sense?)

> > What do you mean by "on the same host"?
> > Are you saying that the machine the compilers produce code for is the
> > same machine as the compilers run on?
> Hmm, let me try to rephrase:
> On my development machine I want to have several compilers (toolchains)
> which are able to produce code that could run on my development machine
> if I would install an older version of glibc.

If you change to an older version of glibc, you might (will!) get
in trouble: expect to see breakage all over the place.

> (Not sure if this makes thing clearer.)

You explained your goal OK. Not quite sure downgrading the libc makes sense,
though.

> What I ultimately want to achieve is to have several compilers on
> my box, so I can generate executables for customers who run systems
> with different versions of glibc and/or linux-headers.

Ah! That's not the same! You indeed want a cross-compiler!
In your case, the machines happen to use the same _processor_ as your
development machine. But they are *not* the same _machine_.

Just consider that your customers' machines are totaly alien to you.

If they had ARM-based machines, you'd want a cross-compiler, surely.
Your tuple would be i486-pc-linux-gnu, while theirs would be something
like arm-unkown-linux-gnu.

If they had the exact same hardware as you, but were using uClibc as their
C library, you'd still need a cross-compiler. Your tuple would still be
i486-pc-linux-gnu, but theirs would be something like i486-pc-linux-uclibc.

So, changing the C library, or the kernel headers (or any other component
for that matters), means you want a cross-compiler.

> One of them hopefully be the mingw target, but I understand that mingw
> is not feasasible yet.

Ah. I really want to do this, so I can cross-build my own Cygwin distribution.
That'd be fun, wouldn't it? :-]

> > You could work this around using the "Vendor string" option (in the menu
> > "Toolchain options"), and set it to something different from your host's
> > tuple. Then you'd build a cross-compiler.
> I tried this, and my
> build  is i486-linux-gnu
> host   is i486-linux-gnu and
> target is i386-custom-linux-gnu
> but during
> [INFO ]  Installing shared core C compiler
> I get:
[--SNIP--]
> [ALL  ]    make[1]: *** No rule to make target
> `../build-i486-build_pc-linux-gnu/libiberty/libiberty.a', needed by
> `build/genmodes'.  Stop.
[--SNIP--]
> I have no idea why ../build-i486-build_pc-linux-gnu/libiberty/libiberty.a
> would be needed at all. Wouldn't this only be needed for executables
> that "run" on the build meachine?

gcc builds some "helper" code for the host. The idea is to get protection
against a badly-coded C library, should that happen. (well it can happen on
weird hosts that do not use a standards-compilant C library).

Hence the iberty library (which is a joke: to link against a library, one has
to use the "-l" flag, directly followed with the library name, "iberty" in
this case, which gives -liberty. gcc folks... ).

> > (In the spirit of crosstool-NG, a "native" compiler whould be able to install
> >  in /, and be used as a replacement for the existing compiler. This raises a
> >  few interesting points, such as headers and library search paths, run-time
> >  paths, and so on...)
> 
> Hmm, the I do not understand what you wrote in overview.txt
> > 1) build == host == target
> >     This is a plain native toolchain, targetting the exact same machine as the
> >     one it is built on, and running again on this exact same machine. You have
> >     to build such a toolchain when you want to use an updated component, such
> >     as a newer gcc for example.
> >     crosstool-NG calls it "native".

This is exactly what I said above. A "native" compiler is meant to be able
to replace the existing native one on the build system/machine, and generate
code for that machine.

> Currently it looks to me as if host != target implies they must not be
> the same machine, yes? (Hmm, altough you said:
> > in the copmpiler land, a "machine" is not only referring
> > to the hardware, but also to a few other parts

Here's what is describinf a "machine": its tuple. If two tuple are the
same, then the two machines are the same. If the tuple differ, then
the machines are not the same.

A tuple is made of 3 or 4 parts:

- 3-part tuple: cpu-vendor-os
  - cpu: the actual CPU used in the machine: i386, arm, mipsel...
  - vendor: a free string (with no dash nor space), also refered to
    as "manufacturer"
  - os: the OS running on the target (although that field is mis-named
    for bare metal machines)

- 4-part tuple: cpu-vendor-kernel-os
  - cpu and vendor: see above
  - kernel: the kernel running on the machine: linux, hurd(?) ...
  - os: the OS variant: gnu, uclibc, gnueabi (for ARM or PPC) ...

Unfortunately, there's no provision for the "gnu" OS version (some OS,
like "winnt", have variants, like "winnt3.5"). So if you want to target
a "gnu" system using a different version of the glibc/kernel headers/gcc/...
you have to differentiate with the "vendor" part.

Unfortunately, you are hitting a bug with what I call "seemingly native
toolchains". Please look in docs/known-issues.txt for the explanations.

> Do you have any suggestions what else I could try?

Sorry. x86 is not my main interest in the (cross-)compiler land. If it
works, I had support. If it breaks I leave in the state, until I have
to make it work for myself, or someone comes with a patch.

Regards, and good luck!
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'

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