public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in  "ld".
@ 2006-08-24  5:03 Kaz Kylheku
  2006-08-24  9:30 ` Kai Ruottu
  0 siblings, 1 reply; 9+ messages in thread
From: Kaz Kylheku @ 2006-08-24  5:03 UTC (permalink / raw)
  To: gcc-help

Hi all,

I am having trouble linking a "hello world" program cross-compiled
for a mips-linux target. GCC can find the headers properly, but
there is some --sysroot silliness going on: mips-linux-ld ends
up catenating two absolute paths, and concludes that it cannot
find libc.so.6, which is there.

GCC is version 4.1.1
Binutils 2.17
Glibc is CVS head.

When configuring gcc, I used --with-sysroot=/path/to/sysroot,
where glibc is installed under usr/. The header files are
found correctly.

When the linker is invoked, it is given

  --sysroot=/path/to/sysroot.

The linker resolves  -lc  to the absolute name
/path/to/sysroot/usr/lib/libc.so.6. But then it catenates that
to the sysroot, resulting in

  /path/to/sysroot/path/to/sysroot/usr/lib/libc.so.6 which is nonsense.

I can see using strace that it's actually trying to access that path.
And so it dies with "cannot find /path/to/sysroot/lib/libc.so.6
inside /path/to/sysroot".

So, what's the /right/ way to coordinate the location of the
target headers and libraries between gcc and binutils when
cross-compiling?

Thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in  "ld".
@ 2006-08-24 19:04 Kaz Kylheku
  0 siblings, 0 replies; 9+ messages in thread
From: Kaz Kylheku @ 2006-08-24 19:04 UTC (permalink / raw)
  To: gcc-help; +Cc: Kai Ruottu

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=/path/to/sysroot,
> > where glibc is installed under usr/. The header files are
> > found correctly.
> >   
>  What about the binutils, was the same '--with-sysroot='
> 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. 

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.
> 
> > When the linker is invoked, it is given
> >
> >   --sysroot=/path/to/sysroot.
> >   
>  Maybe this option is aimed for a 'ld' which was NOT configured
> using the '--with-sysroot='...

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=', only made 
> symlinks like :
> 
>      $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?
:)
 

^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in  "ld".
@ 2006-08-25  0:46 Kaz Kylheku
  0 siblings, 0 replies; 9+ messages in thread
From: Kaz Kylheku @ 2006-08-25  0:46 UTC (permalink / raw)
  To: gcc-help

> I wrote previously
> 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.

I hacked up a silly patch in binutils after which it works. I'm now
happily cross-compling core-utils against glibc for MIPS, on an x86 box.
I've looked at older versions of this function and it didn't have the
else. The idea is to try the catenated name with sysroot, and if that
doesn't work, try the uncatenated name.

I really hate this "solution", but it gets me past a hurdle. I already
have a patched kernel and a patched glibc, so what the heck, right?

I think ld expects gcc to feed it absolute paths which are to be
interpreted relative to the sysroot. But that isn't what gcc is doing:
it's feeding absolute paths from the real system root. It would be nice
if I could figure out how to get gcc to feed absolute paths to collect
which /require/ the root to be tacked on. E.g. /usr/lib/crt<whatever>.o
which would be combined with /path/to/sysroot to create
/path/to/sysroot/usr/lib/crt<whatever>.o.

Ah well.

--- binutils-2.17.orig/ld/ldfile.c      2005-05-12 03:32:02.000000000
-0400
+++ binutils-2.17/ld/ldfile.c   2006-08-24 20:38:38.335091736 -0400
@@ -317,7 +317,8 @@
            }
          free (name);
        }
-      else if (ldfile_try_open_bfd (entry->filename, entry))
+
+      if (ldfile_try_open_bfd (entry->filename, entry))
        {
          entry->sysrooted = IS_ABSOLUTE_PATH (entry->filename)
            && is_sysrooted_pathname (entry->filename, TRUE);

 

^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in  "ld".
@ 2006-08-25 17:56 Kaz Kylheku
  2006-08-28  9:18 ` Kai Ruottu
  0 siblings, 1 reply; 9+ messages in thread
From: Kaz Kylheku @ 2006-08-25 17:56 UTC (permalink / raw)
  To: gcc-help

Solved!

This problem is caused by a miscconfigured glibc build with an incorrect
--prefix. The absolute paths are picked up from libc.so, which is just a
linker script generated by glibc.  This linker script must contain paths
that are correct for the target system system. Of course, those paths
don't work on the cross-compiling system, which is where the catenation
with --sysroot comes in. And of course install_root must be used in
glibc to avoid actually trying to place files at the fictitious --prefix
location. So install_root must match your --sysroot location, and
--prefix is just / . 

Yesterday, I got a mini cross-compiled Linux system to run on real MIPS
hardware, starting from scratch, with very little hints from anywhere. I
just kept doing the "obvious" steps until I got a shell prompt on the
hardware.

How did I debug the problem? Well, after my silly patch to binutils,
which I can now back out, I got everything to link surely enough. But
with the wrong paths. So when I tried to boot the system, my shiny new
/sbin/init was able to fetch the dynamic linker /lib/ld.so.1, but the
dynamic linker quit, with a message about not being able to find
libc.so.6! What? It's right there!

So then I went into the kernel, and compiled an extra environment
variable into init's env[] array, so that I could set it from the kernel
command line. I was then able to "LD_DEBUG=all" on the kernel command
line! I rebooted the MIPS board and ld.so nicely dumped out to the
serial console that it was trying to use build-system paths to look for
the library rather than the correct target-system paths. I band-aided
that with a symbolic link, and got the system to boot, then worked out
the real solution.

^ permalink raw reply	[flat|nested] 9+ messages in thread
* RE: Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in  "ld".
@ 2006-08-29  4:29 Kaz Kylheku
  2006-08-29  8:37 ` Kai Ruottu
  0 siblings, 1 reply; 9+ messages in thread
From: Kaz Kylheku @ 2006-08-29  4:29 UTC (permalink / raw)
  To: Kai Ruottu; +Cc: gcc-help

> Kai Ruottu wrote: 
>  What I have thought being the aim in producing a "normal" glibc,
> one which should work both as a "native" glibc, and as a "cross"
> glibc, is using the '--prefix=/usr'.

In my case, my native system is x86, and the cross one is MIPS.

Even if the architectures are the same, I don't believe in
mixing target code with the development platform. There is
the potential to screw things up.

If you're cross-compiling, you should run the code on the
target system, or in some isolated environment on the development
system (emulator with support for a different CPU if necessary,
chrooted tree, ...).  With chroot, you can have the library
installed in /lib, exactly as on the target.

There is the problem of sharing the same kernel as the host
system too. On my development system, I might be running some
old kernel, but want a newer one underneath the target glibc.

> 
>      make install_root=$sysroot

I patched glibc's configure.in and config.make to support
--with-sysroot, which sets up that variable at configuration time.

It's surprising that such an important variable is left out from
the configuration.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2006-08-29  8:26 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-08-24  5:03 Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in "ld" Kaz Kylheku
2006-08-24  9:30 ` Kai Ruottu
2006-08-24 19:04 Kaz Kylheku
2006-08-25  0:46 Kaz Kylheku
2006-08-25 17:56 Kaz Kylheku
2006-08-28  9:18 ` Kai Ruottu
2006-08-28  9:52   ` Kai Ruottu
2006-08-29  4:29 Kaz Kylheku
2006-08-29  8:37 ` Kai Ruottu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).