From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10172 invoked by alias); 8 Mar 2012 19:09:36 -0000 Received: (qmail 10163 invoked by uid 22791); 8 Mar 2012 19:09:35 -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; Thu, 08 Mar 2012 19:09:22 +0000 Received: by eaal1 with SMTP id l1so258386eaa.0 for ; Thu, 08 Mar 2012 11:09:20 -0800 (PST) Received: by 10.14.28.137 with SMTP id g9mr2541065eea.94.1331233760753; Thu, 08 Mar 2012 11:09:20 -0800 (PST) Received: from [127.0.0.1] (tor18.anonymizer.ccc.de. [31.172.30.1]) by mx.google.com with ESMTPS id z47sm9260376een.5.2012.03.08.11.09.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:09:19 -0800 (PST) Message-ID: <4F5903D2.5020606@googlemail.com> Date: Thu, 08 Mar 2012 19:09: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: Johannes Stezenbach CC: "Yann E. MORIN" , crossgcc@sourceware.org Subject: Re: crosstool-NG 1.14.0 is out References: <201202010100.49177.yann.morin.1998@free.fr> <4F575EAB.1030308@googlemail.com> <20120308144656.GA30302@sig21.net> In-Reply-To: <20120308144656.GA30302@sig21.net> Content-Type: text/plain; charset=ISO-8859-1; 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/msg00024.txt.bz2 > The libc from your build system might have a dependency > on a minimal kernel version, so the statically built > toolchain might not run on very old systems. > Otherwise the static toolchain should be self-contained. > Unfortunately, I had to scrap that idea pretty swiftly :-( As it turns out, what I was planning to do - "emulate" native-cross toolchain in action blew up right in my face! What I did was to build the toolchain with uclibc (the host environment had glibc), then archived the whole toolchain directory and copied it over to the host environment. Finally, with the help of qemu-static, a bit of bin_fmt magic and adjusted path statement the toolchain was executing perfectly. So far, so good, but... When I tried to build a binary (tried to make & install zlib as it is a farily good test on how things work out) it turns out the linker was picking up my host glibc *as well as* the toolchain's uclibc dependency files (i.e. -ldd -root /toolchain/sysroot was clearly showing /lib/ld-Linux as well as /lib/ld-uClibc in addition to the monstrous glibc's own libc.so). After trying to fix that for the best part of a whole day yesterday - unsuccessfully - I finally gave up and I am now using the whole cross toolchain as a proper cross toolchain, which is a real pain as I have to manually compile and install all of the bloody dependencies for what I need to compile for the target. It wasn't all that bad though - I came up with an idea for Yann - I've read the ct-ng readme file (part 5 I think it was) in which there is an explanation of various possible scenarios for sysroot. I am planning to do something similar to option 3 in that list - create an overlay between a staging directory, say /some/place/overlay, which would be read-write, and the toolchain's sysroot and map it to the old sysroot. That way, I could write/install anything freely to the toolchain's "sysroot without actually damaging that directory in any way, while keeping the "written" stuff in a separate directory (the overlay). I'll try that tonight and see where that takes me. Are there any plans to implement cross-native in ct-ng? -- For unsubscribe information see http://sourceware.org/lists.html#faq