[uClibc]uclibc debs

[David Schleef]

On Mon, Jul 02, 2001 at 02:24:04PM -0600, Erik Andersen wrote:
> On Thu Jun 28, 2001 at 05:59:31PM -0700, David Schleef wrote:
> 
> 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)
>     2) Decoupled DEVEL_PREFIX from PREFIX

Pretty random change, actually.  I'm really trying to figure out
all the possiblities of arrangements that people want to have
upon installation.  PREFIX and DEVEL_PREFIX don't seem to cut
it, there may need to be more.  This just happens to work for the
case of making packages.

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

Of course.  You'll also notice that the man pages suck.

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

Er?  It's a good idea, but I didn't actually do that.  I need to
figure out how to Source-Dep on kernel headers first.

>     5) Fleshed out the mips port

Random carryover from my work tree.  Ignore at will, as it doesn't
actually work.

>     6) Changed __USE_POSIX199309 to __USE_POSIX

Ignore.  This was a mistake.

>     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.

The dynamic linker path has to be hard coded into applications.  And
this location has to be standard enough to work on every system.
Going along with the age-old argument "It can't go on /usr, because
you might need to run a dynamic executable to mount /usr", it needs
to be in /lib.  However, I don't see a good reason for not allowing
users to override this location, if they have a pressing desire to
be binary incompatible with the rest of the world.  It would be
smarter to tell people to add a link from /lib/ld-uclibc.so.0 to
whereever.  Working with shared libs effectively requires having
root privileges.

>     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.

It really all depends if you want to be able to put the uC-track
libraries in /lib and /usr/lib on a standard glibc system.  I
was under the impression that this was a goal, but perhaps it
shouldn't be.  Comparing to libc5, sharing directories is
specifically not supported.

(I'm happy to argue the point, but it's for decision making purposes
only, not because I actually believe it is the best or cleanest
solution.)

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

The dependency thing is a problem I fixed along the way.  It's buried
in the other changes.



dave...