[uClibc]uclibc debs

Erik Andersen andersen at lineo.com
Mon Jul 2 20:24:04 UTC 2001


On Thu Jun 28, 2001 at 05:59:31PM -0700, David Schleef wrote:
> 
> I made .deb packages for uclibc, they're at
> 
>   http://www.schleef.org/~ds/debian
> 
> This hack effort was pretty narrow-minded, focusing on decreasing
> the number of policy violations in the packages and getting
> everything into the right place.  Thus, the diff is rather large.
> I'll be merging the simple changes in the next couple days; the
> more complicated changes will require discussion.
> 
> One of the things that was changed is the sonames of the libraries
> to 'libuClibc.so.0', etc.  The -dev packages contains links from
> libc.so, etc., and other packages compile and run correctly this
> way.

Sorry it has taken me a while to review all your changes.  As near as I can
tell, it looks like you have done the following things.  Please correct me if
I've missed anything.

    1) Renamed ROOT_PREFIX to just PREFIX (to more
	closely mimic autoconf behavor)

I have no problem with this

    2) Decoupled DEVEL_PREFIX from PREFIX

Again, no real problem here.  

    3) Added in a debian dir (standard stuff, plus manpages)

fine, though I'd rather the manpages just be part of the source, not the debian
package.

    4) Set it to always install a full copy of the target
	kernel header files

No problem.

    5) Fleshed out the mips port

cool!

    6) Changed __USE_POSIX199309 to __USE_POSIX

why?

    7)
	-       DYNAMIC_LINKER=$(ROOT_DIR)/lib/$(UCLIBC_LDSO)
	+       DYNAMIC_LINKER=/lib/$(UCLIBC_LDSO)

Why?  If I install to  /usr/<arch>-linux-uclibc then this is broken.  Also, this
requires I be root to test/debug the C library.  Bestnot to mess with this, and
ljust leave $(PREFIX) (aka ROOT_DIR) alone.

    8) Changed names from libc.so to libuClibc.so, libresolv.so to libuClibresolv.so, etc.

I'm still thinking about this one.  Things like "libuClibresolv.so" look really
ugly.  And right now, the actual lib names are things like libuClibc-0.9.5.so
and libcrypt-0.9.5.so.  Do we really need to change the sonames though to
avoid conflict?  If we extrapolate this, we need to rename _all_ libraries to
ensure no conflicts ever happen.  libuClibncurses.so?  libuClibssl?  Ick.

Lets take a look at the Debian glibc vs libc5 stuff, as that is the closest
case we are going to find.  For the case of the C lib itself, it uses the
same soname in both cases.  We see:

    /lib/libc.so.6 -> libc-2.2.3.so
    /lib/libc-2.2.3.so

    /lib/libc.so.5 -> libc.so.5.4.46
    /lib/libc.so.5.4.46

Lets double check the sonames:

    [andersen at sage uClibc]$ readelf -d /lib/libc.so.5.4.46| head -n 5

    Dynamic segment at offset 0x8a4d8 contains 16 entries:
      Tag        Type                         Name/Value
     0x0000000e (SONAME)                     Library soname: [libc.so.5]
     0x0000000c (INIT)                       0x10fc0
    [andersen at sage uClibc]$ readelf -d /lib/libc-2.2.3.so| head -n 5

    Dynamic segment at offset 0x10c77c contains 22 entries:
      Tag        Type                         Name/Value
     0x00000001 (NEEDED)                     Shared library: [ld-linux.so.2]
     0x0000000e (SONAME)                     Library soname: [libc.so.6]

So following the example of the other C libs, I chose /lib/libc.so.0 which
seemed like it would be basically consistant with how they were doing things
while not using a well known soname like libc.so.4 or some such...  

    [andersen at sage uClibc]$ readelf -d /usr/i386-linux-uclibc/lib/libuClibc-0.9.5.so| head -n 5

    Dynamic segment at offset 0x23d6c contains 12 entries:
      Tag        Type                         Name/Value
     0x00000001 (NEEDED)                     Shared library: [ld-uclibc.so.0]
     0x0000000e (SONAME)                     Library soname: [libc.so.0]

    /usr/i386-linux-uclibc/lib/libc.so -> libuClibc-0.9.5.so
    /usr/i386-linux-uclibc/lib/libc.so.0 -> libuClibc-0.9.5.so
    /usr/i386-linux-uclibc/lib/libuClibc-0.9.5.so


So the only problem I see is the libc.so link, which may cause us some grief.
So next lets check out a dependant lib, say libm:

    /lib/libm-2.2.3.so
    /lib/libm.so.6 -> libm-2.2.3.so

    /lib/libm.so.5.0.9
    /lib/libm.so.5 -> libm.so.5.0.9

Lets double check the sonames:

    [andersen at sage uClibc]$ readelf -d /lib/libm.so.6 | head -n 5

    Dynamic segment at offset 0x20628 contains 23 entries:
      Tag        Type                         Name/Value
     0x00000001 (NEEDED)                     Shared library: [libc.so.6]
     0x0000000e (SONAME)                     Library soname: [libm.so.6]
    [andersen at sage uClibc]$ readelf -d /lib/libm.so.5.0.9 | head -n 5

    Dynamic segment at offset 0x7278 contains 16 entries:
      Tag        Type                         Name/Value
     0x0000000e (SONAME)                     Library soname: [libm.so.5]
     0x0000000c (INIT)                       0x11c0


Ok, lets see what uClibc does here:

	/usr/i386-linux-uclibc/lib/libm-0.9.5.so
	/usr/i386-linux-uclibc/lib/libm.so -> libm-0.9.5.so
	/usr/i386-linux-uclibc/lib/libm.so.0 -> libm-0.9.5.so

	[andersen at sage uClibc]$ readelf -d /usr/i386-linux-uclibc/lib/libm-0.9.5.so| head -n 5

	Dynamic segment at offset 0x2f430 contains 11 entries:
	  Tag        Type                         Name/Value
	 0x0000000e (SONAME)                     Library soname: [libm.so.0]
	 0x00000004 (HASH)                       0x94

Hmm.  Here I see two potential problems, the libm.so link, and the fact that
libm lacks a dependancy on libc.   

So if we fix up the libc.so, libm.so, etc symlinks, wouldn't that fix things?
I consider the existance of the Debian libc5 packages as proof that this 
scheme can work.  Thoughts?

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--





More information about the uClibc mailing list