installing uclibc runtime on target system

Rob Landley rob at landley.net
Mon Apr 19 01:01:50 UTC 2010


On Sunday 18 April 2010 18:01:51 Matthias Hofmann wrote:
> Hello,
>
> thank you very much for your advice, i am new to this field and some
> things are not so good documented or scattered over the whole internet...

Which is why I need to do an "Embedded Linux From Scratch"...

> while compiling uClibc-0.9.30.2 with the command "make hostutils" i rn
> into the following error:
>
> In file included from ../utils/chroot_realpath.c:23:
> ../utils/porting.h:37:18: error: link.h: No such file or directory
> make[1]: *** [../utils/ldconfig.host] Error 1
> make: *** [hostutils] Error 2

What's your .config, your make command line, and what build environment are you 
building it under?

> I would like to build it under cygwin-1.7.1. is there an additional
> dev-package which i need?

I last used cygwin in 2006.  I've never really used Windows.  I went from the 
C64 to an Amiga to DOS to Desqview to OS/2 to Linux, and I've stayed with 
Linux.

I've _encountered_ Windows a lot over the years, from the time a friend had me 
diagnose why Windows 98 was booting into safe mode (she'd deleted an obscure 
font referenced by one of the help files, therefore the help system was failing 
to initialize, therefore it booted into safe mode) to last week when the hotel 
I stayed at had "The Blue Screen of Death Channel" (which was presumably 
supposed to be the local hotel services channel but was instead displaying the 
Windows blue screen of death for three days).

But I've never written a single program for it, and don't intend to start.  
(I'd rather flip burgers for a living.)

> ---
> So what i did before on my target system is to copy the uclibc lib into
> /lib/uclibc, editing /etc/ld.so.conf to search in that directory as well.

Doesn't the host's library loader also use that?  Seems like a potential 
conflict...

The reason ld-uClibc.so and ld-linux.so have different names is so the library 
loaders can coexist on the same system... and then look in different library 
search paths.

> after that i ran "ldconfig". the library seems to run, but crashes in the
> method which uses the ftruncate... functions.

Is this the first C library call it tries to run, or is that just the first tone 
that failed?

  Step 1: Does a statically linked "hello world" work?
  Step 2: Does a dynamically linked "hello world" work?
  Step 3: Does your app work?

> a shared library compiled
> with glibc runs without any problems so it looks to me that it is either
> an compatibility-problem concerning shared memory (unlikely) or a faulty
> uclibc runtime.

Could be a number of things.  Let's figure out what _is_ working, and work our 
way up.

What target are you trying to run the result on?  (Presumably a 2.6 Linux 
kernel, since you meantion glibc?  Existing distro, or did you build it 
yourself?  Built for x86?  x86-64?  Arm?)

> so what i have to do now is simply copying the libraries into /lib and the
> ld-uclibc file into /usr.

Start by getting a statically linked version working, so you know the app 
works and the problems you're seeing are only with the library loading.  (If 
the app isn't working and you're trying to fix it by fiddling with shared 
library search paths, you'll waste your time.)

> But there are some libraries with the same name
> in the directory (likely glibc-versions) which i did not want to
> overwrite.

Then it will pull in the wrong ones, and fail.

In the uClibc source, in ldso/ldso/dl-elf.c, there's this:

        tpnt1 = search_for_named_library(libname, secure,
                                        UCLIBC_RUNTIME_PREFIX "lib:"
                                        UCLIBC_RUNTIME_PREFIX "usr/lib"
#ifndef __LDSO_CACHE_SUPPORT__
                                        ":" UCLIBC_RUNTIME_PREFIX 
"usr/X11R6/lib"
#endif
                                        , rpnt);

Someday I'm likely to send a patch upstream to replace UCLIBC_RUNTIME_PREFIX 
with UCLIBC_RUNTIME_PATH because append "lib" and "usr/lib" to the path I 
specify prevents me from saying UCLIBC_RUNTIME_PREFIX="/lib-x86_64" or 
similar.

But for the moment, UCLIBC_RUNTIME_PREFIX can be specified in menuconfig, and 
that's probably what you want to do.  Feed it "/uclibc/" or some such.  Notice 
the trailing slash, since the above is _NOT_ adding a slash at the beginning, 
for reasons that also make no sense to me, but oh well...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the uClibc mailing list