[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