glibc; introducing slashpackage-foreign (was: GNU Mach panic)

[Thomas Schwinge]

[ Cc'ed to the slashpackage-foreign list
  <URL:mailto:spf@multivac.cwru.edu>. ]

[ Replied publically with Alfred's permission. ]

On Sun, Mar 06, 2005 at 09:28:43AM +0100, Alfred M. Szmidt wrote:
>    rm {nptl,linuxthreads}/configure
> 
> Why?

When using 'configure [...] --enable-add-ons' to tell glibc's build
system that all available add-ons should be built, the build will fail
at the time it tries to build the said add-ons.
Perhaps I should implement '--disable-add-ons=[...]' or the nptl and
linuxthreads add-ons should be disabled for GNU/Hurd.

>    CFLAGS='-O2 -g -pipe --march=athlon-xp'
>    ASFLAGS=$CFLAGS
> 
> Don't use this.

Only '--march=athlon-xp' could cause problems here, because '-O2 -g' is
configure's default for CFLAGS when using GCC and '-pipe' really
shouldn't hurt.


Since GNU/Hurd also is about developing advanced techniques compared to
other UNIXy systems:

>    configure --prefix=[...] --with-headers=[...] --without-gd --without-cvs \
>      --disable-profile --enable-add-ons --without-tls 
> 
> Could you try using normal flags?  Like:
> 
> ../configure --prefix= --without-cvs --disable-profile --without-tls
> 
> I fail to see why you must specify the flags that you do to begin
> with.

I have to use './configure [...] --prefix=[...] --with-headers=[...]'
because I have every package installed into its own hierarchy of
directories using a system called slashpackage-foreign
<URL:http://code.dogmap.org./spf/>.
This is an extension of Dan Bernsteins slashpackage hierarchy
<URL:http://cr.yp.to/slashpackage.html>.

Installing packages that way has a lot of advantages compared to the
established way of doing that on UNIXy systems.
* Reliability of paths.
  The Python interpreter will always be available as
  '/package/misc/spf/python/bin/python'.
  No need for '#!/usr/bin/env python' hacks.
* The ease of having multiple versions of a package installed.
  A package compiled against glibc-2.3.2's shared libraries can continue
  to use those even if glibc-2.3.4 or glibc-HEAD are installed
  afterwards.  (Of course that old package can also be told to use the
  binary compatible glibc-2.3.4 containing bugfixes.)
* ...

Everyone, feel free to ask questions if you want to know more about
that system.


Regards,
 Thomas