[ Cc'ed to the slashpackage-foreign list
<URL:mailto:[EMAIL PROTECTED]>. ]
[ 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
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
