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: crosstool-NG 1.14.0 is out



Hello all!

I'm pleased to announce the release of crosstool-NG 1.14.0!

As usual, there has been quite a number of improvements, new features,
and bug fixes all around. The most notable changes are listed below:

- features:
- initial support for multi-lib
- build manuals for components that have manuals
- add support for NLS
- optionally optimise newlib for size
- archs:
- ARM: introduce softfp
- x86: recognise prescott as an i686
- updated components:
- gcc: 4.6.2, Linaro 4.5 and 4.6
- strace: 4.6
- linux: multipe updates, and up to 3.2
- glibc: 2.14.1
- mpfr: 3.1.0
- binutils: 2.22
- gdb: update Linaro versions
- uClibc: 0.9.32.1
- infrastructure:
- configure: now uses autoconf
- configure: computes local version
- scripts: execution backtrace is now properly dumped
- documentation:
- strategies for assembling root filesystems
It has been a while since I last tried crosstool-NG out (was happy with the cross-toolchain I've build for my e604 nearly a year ago now), but since I upgraded to the above version, I was even more pleased, thank you! The build is much more streamlined now and there are less "teething" problems, though I still get the same rather annoying CLooG/PPL build failure as I used to get it before (using version 0.10.1 prior to this), so I had to deactivate this option yet again. I have three questions though:

1. When I try "ct-ng tarball" after the toolchain build is complete, I get a message that this feature is not implemented. Correct me if I am wrong, but isn't this target the equivalent of just changing to the chainroot directory and executing tar (selecting one's favoured archive format - that being a simple .tar, tar.gz/tgz, tar.lzma or tar.xz even) all that is required of this or am I missing something obvious? What is the reason behind this feature/target not being implemented?

2. Due to compatibility issues, which I might bother you in subsequent posts, I built a static toolchain (that is, statically-linked <target tuple>-gcc/ld etc files). The file size I am getting varies between 1MB and 2MB, which for statically-linked files is quite normal, I think. That way, I take it, these executables will be shielded from the host environment and won't require *any* external dependencies, right?

3. My initial aim was to build cross-native toolchain (build != host = target), but since I realised there is "no code" for this implementation, I opted to build a simple cross-toolchain (build = host != target) instead, the idea being is that I could employ static qemu on the host machine using the bin_fmt magic and in this way I could use the cross-toolchain I just built - that was another reason to also build it statically-linked. So, the question is - is cross-native toolchain in the pipeline to be implement and how easy is it to do so?

The second
one is the ARM softfp support; ARM softfp is using hardware instructions,
but uses software floating point ABI, thus making it compatible with 'legacy'
soft-float libraries.
This is the feature I am very pleased with! Brilliant!


MZ


--
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]