[uClibc]compiling lshw with uClibc
Erik Andersen
andersen at codepoet.org
Tue Mar 25 18:59:12 UTC 2003
On Mon Mar 24, 2003 at 04:21:28PM +0100, Roland Nagtegaal wrote:
> On Fri, Mar 21, 2003 at 12:51:58PM -0700, Erik Andersen wrote:
> > If you _really_ want to compile your own C++ toolchain, go here
> > http://uclibc.org/cgi-bin/cvsweb/toolchain/
> > click on "Download tarball" and then you can compile your own.
> > Unless you really know what you are doing though, I do not
> > recommend you make your own. I think you should grab
> > http://www.uclibc.org/downloads/root_fs-i386.bz2
> > and compile the things you need using that, which will let you
> > easily see how big things are with uClibc.
>
> I already did that, but lshw does not compile with the toolchain
> that comes with root_fs-i386.bz2 .
> So, the libstd++ in root_fs-i386.bz2 is not good to compile lshw.
You realize that as bug reports go, this one is pretty usless?
If "the libstd++ in root_fs-i386.bz2 is not good" maybe you could
describe the problem you are having so I could fix it.
> So my question really is where do I get libstd++ (gnu.org ?) and how do I
> compile it within root_fs-i386.bz2 ?
libstd++ is built as part of gcc. If you go to
http://uclibc.org/cgi-bin/cvsweb/toolchain/
as I suggested, you will find a Makefile to build your own
toolchain including libstd++. But it will be just like the
one on root_fs-i386.bz2 that "is not good".
> > You probably did not strip your ls binary to remove debugging
> > symbols. Generally, binaries compiled with uClibc are either
> > the same size or smaller than when compiled using glibc.
>
> It is stripped, I checked that of course. But the redhat library dependancies
> are much heavier.
>
> This is when I'm chrooted in "root_fs-i386.bz2":
>
> [root at bosch /]# ls -al /bin/ls
> -rwxr-xr-x 1 root root 77196 Mar 21 05:33 /bin/ls*
> [root at bosch /]# strip /bin/ls
> [root at bosch /]# ls -al /bin/ls
> -rwxr-xr-x 1 root root 77196 Mar 24 07:57 /bin/ls*
>
> ... and this is in plain redhat 7.3:
>
> [root at bosch roland]# ls -al /bin/ls
> -rwxr-xr-x 1 root root 46888 Mar 25 2002 /bin/ls
>
> the uClibc compiled /bin/ls depends on:
> [root at bosch /]# ls -al /lib/libuClibc-0.9.19.so /lib/ld-uClibc-0.9.19.so
> -rwxr-xr-x 1 root root 16844 Mar 6 11:34 /lib/ld-uClibc-0.9.19.so*
> -rw-r--r-- 1 root root 244300 Mar 6 11:34 /lib/libuClibc-0.9.19.so
>
> ... and the redhat 7.3 one depends on:
>
> [root at bosch roland]# ls -al /lib/libtermcap.so.2.0.8 /lib/libc-2.2.5.so /lib/ld-2.2.5.so
> -rwxr-xr-x 1 root root 89547 Oct 10 16:58 /lib/ld-2.2.5.so
> -rwxr-xr-x 1 root root 1260480 Mar 24 16:00 /lib/libc-2.2.5.so
> -rwxr-xr-x 1 root root 11832 Jul 10 2001 /lib/libtermcap.so.2.0.8
>
> So, the uClibc version of ls is actually bigger, but the redhat version depends
> on much bigger libraries. So the uClibc version would use 5 times less space
> on my disk.
Ok. Yes you are correct. But this is simply an issue with the
configuration of GNU coreutils used for root_fs and has pretty
much nothing to do with uClibc. I can look into the coreutils
configuration as I have time. But honestly, if you want stuff
that is nice and small, use busybox. The uClibc root_fs is not
intended for people to copy binaries from. It is to allow people
to easily compile their own stuff with uClibc.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
More information about the uClibc
mailing list