[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