[uClibc]Question on library search dirs

[Joel Coltoff]

Hi,

I'd like to know if I can build my gcc so that when I do

	mipsel-uclibc-gcc --print-search-dirs

/usr/lib and /lib are in the list. I want to do this because I've
built a compiler that runs on my embedded box. Now it looks in these
dirs.

  /opt/uclibc/lib/gcc-lib/mipsel-linux/3.2/
  /usr/lib/gcc/mipsel-linux/3.2/
  /opt/uclibc/lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib/mipsel-linux/3.2/
  /opt/uclibc/lib/gcc-lib/mipsel-linux/3.2/../../../../mipsel-linux/lib/
  /opt/uclibc/mipsel-linux/lib

However, the runtime environment isn't going to look here. What complicates
this is that the paths in the host based toolchain and the embedded version
are different. Yes they could be the same but one customer (they are always
right as you know) doesn't want that. They don't care so much about the
embedded side but the host is an issue for them. This means one of the
following

    1) 2 copies of each library so that both the compiler and runtime
       dynamic loader can find them.
    2) Use symbolic links so that the toolchain lib points to /lib
    3) In the host based toolchain set TARGET_PREFIX to set
       UCLIBC_TARGET_PREFIX so the runtime loader points to the toolchain
       library

The release is set up so that the dynamic loader comes from the host. This
is why number 3 exists as a choice. Customers that want the compiler will
add it as a package. If my embedded toolchain could look in /usr/lib
and /lib then, to my way of thinking, the installation is cleaner. Did I
ask this in a way that makes sense? Has anyone done something similar and
found a clean solution? It will also leave the libraries where most people
expect them to be.

Thanks.

-- 
Joel Coltoff

Perfection, then, is finally achieved, not when there is nothing left
to add, but when there is nothing left to take away.
    -- Antoine de Saint-Exupery