Re: Opinions requested

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Harold, All,

On Sunday 22 August 2010 15:53:17 Harold Grovesteen wrote:
> A few up front comments to provide some context. ?Yes, the toolchain is
> statically built.

No, the toolchain is not statically built. It builds static binaries, but
the toolchain itself (eg. gcc, ld, as...) are still shared executables.
See the difference? ;-)

> What I am seeking here is an assessment from those much more 
> knowledgable about the process, the pros and cons, and is it worth 
> integrating into crosstool-NG.  For that I would be willing to do the 
> work.

I don't care adding a new target system, provided that it fits in
the current framework. If it was to break existing stuf, then no.

> I realize this might be a special case with very limited  
> applicability, but it is so simple and easily created I thought I would 
> bring it up here.  I have never seen a crosstool build this simple.  If 
> it is, maybe it should be documented somewhere.  What's the gotcha?

The 'gotcha' is that it is not standard. :-) A non-POSIX API is a bit weird.

> My suspicion is that glibc and Linux bring the complexity to the build 
> process.

Definitely.

Linux is a very special kernel. It's userland API evolves with each version
(for the better!), adding new features (some stuff can get removed, but
that's a very, very long process, and seldom happens).

On the other hand, the C library (eg. glibc, uClibc...) also provides an
API to programmers, relying on the kernel to do the actual stuff. When the
kernel lacks something, then the C library emulates it. A good example is
the support for threads: before the Linux kernel had threads, the C library
provided the LinuxThreads implementation that emulated threads purely in
userland. Now the kernel has Native POSIX Thread support, the C library can
use that to provide threads via the NPTL. Another example is AIO, which has
to be emulated with threads, as the kernel lacks AIO (I'm not sure AIO is
now in the Linux kernel).

So, with the Linux kernel, the C library has to know the userland API before
it can be build, as it has to know what it can use from the kernel, and what
it has to emulate because it is missing.

> Once those two elements are removed from the process (as this  
> does), it becomes straight forward.  And those two elements missing from 
> this process might also be what relegates it to a niche application.

In fact a lot of kludges and hacks in CT-NG are to take care of old versions,
of shared libs, threads and othe languages besides C. As your toolchain lacks
all the above, its build process can be expurged of many, many kludges. :-)

Indeed, your use-case seems to be very, very specific. Nonetheless, adding
it to crosstool-NG might be feasible.

> Build binutils:
> 
> ../../src/binutils-2.20/configure 
> --prefix=/home/xxxx/hercules/c4vm/cross/run --target=s390-linux \
>      --enable-install-libbfd
> make -j
> make -j install

binutils can use GMP and MPFR. Build them before binutils.

> Build gmp:
> ../../src/gmp-5.0.1/configure 
> --prefix=/home/xxxx/hercules/c4vm/cross/sup --disable-shared

That's OK. In CT-NG, we also enable additional stuff, such as FFT and
mpbsd support.

> Build mpfr:
> Build mpc:

Both build as in CT-NG.

> Build gcc:
>  ../../src/gcc-4.5.1/configure \
>     --prefix=/home/xxxx/hercules/c4vm/cross/run \
>     --target=s390-linux \
>     --enable-languages="c" \

And what about others, eg. C++ ?

>     --with-newlib \
>     --without-headers \

Which in gcc terminology means "with no C library" (almost).

>     --disable-threads \
>     --disable-shared \
>     --with-gmp-include=/home/xxxx/hercules/c4vm/cross/sup/include \
>     --with-gmp-lib=/home/xxxx/hercules/c4vm/cross/sup/lib \
>     --with-mpfr-include=/home/xxxx/hercules/c4vm/cross/sup/include \
>     --with-mpfr-lib=/home/xxxx/hercules/c4vm/cross/sup/lib \
>     --with-mpc-include=/home/xxxx/hercules/c4vm/cross/sup/include \
>     --with-mpc-lib=/home/xxxx/hercules/c4vm/cross/sup/lib

The options --with-foo-lib=... and --with-foo-include=... are deprecated.
Use --with-foo=... Eg. --with-gmp=/home/xxxx/hercules/c4vm/cross/sup

Also, you can use three other libs to take full advantage of gcc optims:
- ppl           (eg. for loop unrolling)
- CLooG/ppl     (ditto)
- libelf        (for link-time optimisation, LTO)

Really, I can see no hard issue to add that to crosstool-NG. Just describe
a new 'kernel', make it depend on s390 only, and have it support only the
'none' C library. That should be no harder.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  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