Re: crosstool-NG 1.14.0 is out

[Michael Zintakis <michael.zintakis@googlemail.com>]

> 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