This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Opinions requested


Yann E. MORIN wrote:

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++ ?

I don't think C++ is in the plans here. C itself will be




--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, Thanks, for your response and clarifications. While this scenario is indeed quite specific, I suspect the use case is not as rare, although also not common. Anyone doing bare-metal coding, and OS's are just the usual example, is faced with the need for a tool chain that can create executables but has no POSIX interface, it does not initially exist, and there aren't OS header considerations at that stage either because it might not be Linux, although usually ends up being that.

I am glad it is not sufficiently out of scope for crosstool-NG inclusion. I suspect once the example exists, others may find it useful. We will probably want to explore your suggestions as well. I will wait awhile for the state of this to settle down before I start to work on adding it. This toolchain was recently devised by my co-developer on Hercules and shared with me. I would like to see how the toolchain burns in (you know, surprises!) before I commit to working on adding it.

Again, thanks so very much,
Harold Grovesteen


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]