From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11704 invoked by alias); 7 Mar 2012 13:12:54 -0000 Received: (qmail 11562 invoked by uid 22791); 7 Mar 2012 13:12:53 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_QE X-Spam-Check-By: sourceware.org Received: from mail-ey0-f169.google.com (HELO mail-ey0-f169.google.com) (209.85.215.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 13:12:25 +0000 Received: by eaal1 with SMTP id l1so2336058eaa.0 for ; Wed, 07 Mar 2012 05:12:24 -0800 (PST) Received: by 10.14.98.206 with SMTP id v54mr906478eef.82.1331125944486; Wed, 07 Mar 2012 05:12:24 -0800 (PST) Received: from [127.0.0.1] (tor18.anonymizer.ccc.de. [31.172.30.1]) by mx.google.com with ESMTPS id w9sm16159260eei.8.2012.03.07.05.12.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 05:12:23 -0800 (PST) Message-ID: <4F575EAB.1030308@googlemail.com> Date: Wed, 07 Mar 2012 13:12:00 -0000 From: Michael Zintakis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 MIME-Version: 1.0 To: "Yann E. MORIN" CC: crossgcc@sourceware.org Subject: Re: crosstool-NG 1.14.0 is out References: <201202010100.49177.yann.morin.1998@free.fr> In-Reply-To: <201202010100.49177.yann.morin.1998@free.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00013.txt.bz2 > 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 -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