[uClibc] Re: [OT] Re: The naming wars continue...

Ivan Popov pin at medic.chalmers.se
Fri Oct 29 08:34:40 UTC 2004


Hi Dave!

We are going offtopic, but as people here are dealing with libraries,
versions and distributions, it feels ok to cc: to the list.

> As for my "much crazier ideas", that stems mostly from version
> mismatch problems that have popped up over the years.  I also have
> issues with configure scripts that are too aggressive and find
> libraries and headers that I _don't_ want them to use.  I want to be
> able to have minor versions X.1.1 and X.1.2 of a library installed at
> the same time, and control on a per-application basis which one is
> seen at compile time and runtime.  And I want to have X.1.1 and X.1.2
> self-contained, so that uninstallation of either one is trivial.  No,
> I don't have any idea yet how this would be managed from user space :-)

When you say it. I _do_ manage it totally from user space (at the price
of extra exec() syscalls and long pathnames). It works well and gives one
total control over the versions. It does not create a reason for collisions.

I am comfortably running a mix of glibc, bsd libc and uclibc.
Inside the same sessions. Exact versions I want.
Without making other versions inaccessible.

Though I am using a global filename space, you can deploy the same tools
and structures for any "globality", say it would work on all hosts where
your home directory has the same pathname.

Of course, you can always use it on a single host, if you do not have
or want connectivity and mobility :)

Downside - you have to give up a remarkable part of "auto*" tools
functionality - due to their inherent inability to read our minds :)

The project has grown out of work on among other things the problems
you outline above.

My best regards and apologies to uninterested parties...
--
Ivan
http://www.konvalo.org




More information about the uClibc mailing list