[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
[[!meta title="Nix-based GNU/Hurd System, Guix"]]
This QEMU image is not (yet) comparable to NixOS, because the latter provides
extra features, such as whole-system configuration (including services, etc.),
and whole-system transactional update and rollback. It is is cross-built using
Nix, and because of that, it uses per-package installation directories under
## IRC, freenode, #hurd, 2013-02-04
is it possible to use nix ?
you mean the Nix-based Hurd image?
it's currently broken:
aw, nixos uses systemd :(
yeah, but the Hurd image is a different thing
is uses runsystem.sh™
i've been willing to unbreak it, but now i rather invest time in
## IRC, freenode, #hurd, 2014-02-13
is debian hurd the only way to use hurd?
there is arch hurd but i haven't heard from them in some time
building from source is difficult
what is the problem with building from source?
no automated build system, except for debian
each project has its own build system
but there is no tool to take care of the global procedure
(i.e. build in the correct order, with the correct options, paths and
well, there is, it's called Debian :)
00:17 < braunr> no automated build system, except for debian
how far away is it from building a gnu system with let's say
guix as a package manager?
and hurd as the kernel?
i don't know
phant0mas: there are already proofs of concepts
youpi: any more info about the proofs of concepts?
phant0mas: ask civodul
apparently he's not here atm, though
I will ask him at guix channel
## IRC, freenode, #hurd, 2014-02-14
can I ask a question about configuring gnu mach from source?
phant0mas: IRC etiquette: don't ask to ask, just ask, it saves
time. People often leave IRC open for long durations but don't always
check it, if you just leave your question in the channel someone might
come back and see it at any time (even hours later).
when I try to configure gnumach with
CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld
-melf_i386' ./configure --prefix= --host=i686-unknown-linux-gnu
on a 64 bit system
I get the error
checking for i686-unknown-linux-gnu-gcc... gcc -m32
checking whether the C compiler works... no
configure: error: in `/home/manolis/Downloads/gnumach-1.4':
configure: error: C compiler cannot create executables
but if I remove the -m32 from CC='gcc -m32' the error
what is the problem?
what do you think there is a problem ?
i don't think -m32 should be part of CPP/CC, but rather CPPFLAGS
also, i don't think you need it since the target is well defined
I am following exaclty the instruction from here
hm that's weird
phant0mas: what does gcc -v says and what's your host system ?
Using built-in specs.
Configured with: /build/gcc/src/gcc-4.8-20131219/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-
object --enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-plugin
--disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20131219 (prerelease) (GCC)
check config.log for the actual error message then
if you want to have a look as well
install gcc-multilib maybe
Installing gcc-multilib solves it.
braunr: it works like a charm now
## IRC, freenode, #hurd, 2014-02-18
why mig has no make target, and the executable gets generated
from the ./configure?
I mean shouldn't make be the one building mig?
## IRC, freenode, #hurd, 2014-02-19
mig binary shouldn't be built by make? why is it built at the
end of the configure command?
"creating mig" you mean ?
loot at the end of the config output
config.status: creating mig <--
and then when you call make
it says no target
normally binaries are built from make
what system are you building on ?
on Arch Linux x86_64 with gcc version 4.8.2
I am using the flag i686-pc-gnu to crossbuild it for 32 bit
I am using the tar file from here
tar file ?
ok, i guess it's fine
so source from the tar file builds mig through configure?
again, i don't know
i never build mig myself
but it does look weird
look at the debian package maybe
who knows, maybe you'll find a patch with some explanation
okay then,going over that way right away
phant0mas: mig is a shell script wrapper
so it's not a binary....
## IRC, freenode, #hurd, 2014-02-21
do I need some minimal set of drivers to build gnumach?
because I get this error
../linux/src/drivers/scsi/BusLogic.c:53:24: fatal error: FlashPoint.c: No
such file or directory
when running make
i thought we fixed that
are your sources up to date ?
I am using the tar ball
cause I am trying to package it for guix
what tarball ?
phant0mas: just don't build scsi drivers
why do we keep the driver if it doesn't even build ?
on debian it builds with --disable-net-group --disable-pcmcia-group
## IRC, freenode, #hurd, 2014-02-23
why when I configure gnumach like this CPP='gcc -m32 -E -x c
-undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ./configure --prefix=
--host=i686-unknown-linux-gnu it builds just fine but when I try to
configure it with ./configure --prefix= --host=i686-unknown-linux-gnu
CFLAGS='-m32' CPPFLAGS='-m32 -E -x c -undef -ansi' LDFLAGS='-melf_i386'
I am building it on a 64 bit machine
when setting env vars before configuring everythings works like
but if I pass them as flags to the configure ,it won't
## IRC, freenode, #hurd, 2014-02-25
what version of mae do I need in order to compile glibc for
phant0mas: did you have issues with a particular version?
I believe GNU make is required, though
I am using gnu make 4.0 and I get the error
These critical programs are missing or too old: make
checking version of gmake... 4.0, bad
phant0mas: that sounds bogus
can you pastebin the relevant part of the config.log or so?
of course one sec
azeem_: any news about the problem I have with glibc?
phant0mas: sorry - got distracted - I suggest you post this to
bug-hurd or so
though it could well be Hurd-independent, then checking glibc
master and possibly filing a report there might be better
phant0mas: or in case you speak autoconf, check the conf check for
the make version
## IRC, freenode, #hurd, 2014-02-26
ph4nt0mas: Which glibc sources, and how are you
tschwinge: I am trying to crossbuild it from a linux 64 bit
machine with gnu make 4.0 and gcc 4.8.2
I am using the last one
it says gnu make is too old
this time I tried with glibc from the hurd git repo
should I build an older toolchain just for it?
phant0mas: If you'd like to experiment with this, then please
use the tschwinge/Roger_Whittaker branch. However, that one might still
be missing the glibc upstream change to allow GNU Make 4.0 and greater,
commit 28d708c44bc47b56f6551ff285f78edcf61c208a, so cherry-pick that one
(assuming there are no additional patches needed for GNU Make 4.0).
okay going to do that right away
phant0mas: You have seen
http://www.gnu.org/software/hurd/toolchain/cross-gnu.html -- but beware
this may be out of date somewhat.
tschwinge: I worked around that problem as you told me
but it seems I forgot to build hurd
so I got the tarball
but I am getting this error
No rule to make target 'lowlevellock.h', needed by 'timefmt.o'.
after I manage to make all of this work I will write an up to
date guide on how to build the hurd system
for future reference
## IRC, freenode, #hurd, 2014-02-27
when trying to build gnumach microkernelin a 32 bit enviroment
it builds just fine
but when i try to crossbuild it from a 64 bit machine, even
though i am using --target=i686-gnu --host=i686-gnu to crossbuild it I
am just getting the error i386/i386/i386asm.symc:116:1: warning: asm
operand 0 probably doesn't match constraints [enabled by default]
i386/i386/i386asm.symc:116:1: error: impossible constraint in
and the build output if anyone want to have a look
I am building through guix so you may see some strange paths
ph4n70m4s: Nice, Guix! :-)
ph4n70m4s: Does that help? CC=gcc\ -m32
configure:3574: gcc -v >&5
Using built-in specs.
guix looks nice
ph4n70m4s: Also you don't need --target with GNU Mach -- it
doesn'T target any architecture, that is, doesn'T create code or similar.
Alternative to -m32, as you're specying --host=i686-gnu, you
could have (that is, you'd need) a i686-gnu-gcc (that internally defaults
to -m32 then).
ph4n70m4s: Are you generally working on GNU Hurd support for
Guix, or just trying to build GNU Mach?
I am working on porting gnu guix to gnu hurd
so I need to port hurd to it
and the make guix work on hurd
very cool :)
and If I manage to do all that we will be able to make a qemu
with hurd -guix
Yep, and then I'll be happy. :-)
For then we'll be easily able to change some detail in, say,
glibc, rebuild the whole system, and see whether it still works.
Of course, that doesn't strictly need Guix, but it's one way to
achieve this goal.
For the initial cross compiler toolchain, I suggest you look at
my cross-gnu script (link provided yesterady) -- the gist of it should
all still be valid.
For example, you don't actually need to build GNU Mach
initially, but just need to install the headers/defs files
I have already done that, installing gnu mach headers was the
it's already on guix
Should really clone Git repository. And subscribe to the
mailing list, and all that.
I have already done that
I am actually following hurd from last year
Yeah, I was talking about me. ;-)
ph4n70m4s: Are you doing this as a Google Summer of Code
I suggested the idea for the page
and he agreed
Both of you. ;-)
trying my best to help :-)
tschwinge: so to build glibc I only need mach and hurd headers
## IRC, freenode, #hurd, 2014-02-28
tschwinge: In your cross-gnu script while configuring hurd you
--without-parted . Why do we need to pass these flags to it?
well, --disable-profile turns off profiling afaiui
you should keep it
--without-parted is not needed if you have libparted
## IRC, freenode, #hurd, 2014-03-01
The hurd tarball has as a dependency autoconf
normally it shouldn't, right?
phant0mas: you mean there's no configure script?
no no, for some reason the configure script states as
dependency autoconf which it shouldn't as it is a tarball
phant0mas: how does it state that?
you already have the configure script in it
you get an error running it saying autoconf is required?
actually it gives an error for autoconf and git
but if you have autoconf ,it forgets about git
## IRC, freenode, #hurd, 2014-03-02
youpi: civodul told me you are the one to ask about libpthread
how should I handle Hurd's libpthread in order to build it,with
the rest of the hurd system?
anything I should be extra carefull?
I am building it from the tarball
phant0mas: nothing I can think of
## IRC, freenode, #hurd, 2014-03-03
youpi: what does libpthread do when we do "make
Does it patch the mach headers in the prefix folder?
tschwinge: why do we need this flag passed to configure at
phant0mas: I don't remember such detajils of the build system
I am studying the cross-gnu script from tschwinge
and if I try to call configure without that flag I am getting
configure: error: need libihash
Well, there's this comment: # `$TARGET-gcc' doesn't work yet
(to satisfy the Autoconf checks), but [...]
At this point we're only intested in the header files, so that
was the "path of least resistance".
so we are only interested in the headers of libpthread?
do I need to pass as --prefix the folder which the include
folder with the mach headers are installed?
I wonder whether it'd be better for you to directly include
libpthread in glibc, as Debian is doing -- probably yes.
maybe it would be much simpler that way
let me check the debian package
i'd consider it mandatory, since libpthread can't work correctly
now if it's not part of glibc
## IRC, freenode, #hurd, 2014-03-05
braunr: did i understand it correctly that our libpthread needs
if so, won't that be a problem for phant0mas bootstrapping
apparently, they're used only for thread-specific data