From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7568 invoked by alias); 24 Aug 2006 18:01:27 -0000 Received: (qmail 7560 invoked by uid 22791); 24 Aug 2006 18:01:27 -0000 X-Spam-Check-By: sourceware.org Received: from mail.zeugmasystems.com (HELO zeugmasystems.com) (192.139.122.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Aug 2006 18:01:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in "ld". Date: Thu, 24 Aug 2006 19:04:00 -0000 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D3655F7@exchange.ZeugmaSystems.local> From: "Kaz Kylheku" To: Cc: "Kai Ruottu" X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-08/txt/msg00220.txt.bz2 Kai Ruottu wrote: > Kaz Kylheku wrote: > > GCC is version 4.1.1 > > Binutils 2.17 > > Glibc is CVS head. > > > > When configuring gcc, I used --with-sysroot=3D/path/to/sysroot, > > where glibc is installed under usr/. The header files are > > found correctly. > >=20=20=20 > What about the binutils, was the same '--with-sysroot=3D' > given in their configure? I did rebuild binutils using --with-sysroot, only because the they complain that they were not built with sysroot support and bail out. It doesn't matter at all what the --with-sysroot argument is for configuring binutils. You can even omit it. If I take the non-working collect2 command line (captured from gcc -v), and edit out the --sysroot, it links! It's the --sysroot being passed down to ld that is screwing things up. The gcc front end is already passing nice absolute path names down for everything: the crtN modules, the -L option to find libs, etc.=20 I think I just have to figure out the way to configure gcc to do all that exactly as it is doing now, but not generate the --sysroot option. I really want to avoid patching it. There is an Autoconf check in gcc to test whether the linker understands --sysroot. That should have worked the first time when I built gcc using --with-sysroot with binutils compiled without sysroot. Ah, but the problem is that the configure script only runs "ld --help" and greps that for --sysroot. If you build ld without sysroot, it still has that option listed in its --help output. Oops! > Finding the headers happens with the built-in 'cpp' in the > 'cc1', 'cc1plus' etc. real compilers, so only the GCC config > options will have any influence to this. >=20 > > When the linker is invoked, it is given > > > > --sysroot=3D/path/to/sysroot. > >=20=20=20 > Maybe this option is aimed for a 'ld' which was NOT configured > using the '--with-sysroot=3D'... Shrug. I don't see the point of giving a sysroot to a tool, and at the same time, giving it absolute path names to all of the objects and directories. It would perhaps make sense if the paths were relative to the root. > I myself haven't used the '--with-sysroot=3D', only made=20 > symlinks like : >=20 > $prefix/$target/include -> $sysroot/usr/include > $prefix/$target/lib -> $sysroot/usr/lib I thought about symlinks, but the problem is they are too much of a bandaid. This stuff is supposed to work, right? If we can't get gcc to cleanly play along with binutils, where are we? :) =20