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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |