From de3f3f6cc52d1e5013e85137d09f2ac23e657858 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Mar 2014 20:10:58 +0100 Subject: IRC. --- hurd/running/nix.mdwn | 467 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 464 insertions(+), 3 deletions(-) (limited to 'hurd/running') diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn index 332fc03b..c6212da8 100644 --- a/hurd/running/nix.mdwn +++ b/hurd/running/nix.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,7 +9,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="Nix-based GNU/Hurd System"]] +[[!meta title="Nix-based GNU/Hurd System, Guix"]] + +[[!toc]] + + +# Nix @@ -25,7 +31,7 @@ Nix, and because of that, it uses per-package installation directories under `/nix/store`. -# IRC, freenode, #hurd, 2013-02-04 +## IRC, freenode, #hurd, 2013-02-04 is it possible to use nix ? or nixos @@ -39,3 +45,458 @@ Nix, and because of that, it uses per-package installation directories under (my favorite) i've been willing to unbreak it, but now i rather invest time in Guix + + +# Guix + +## + +## IRC, freenode, #hurd, 2014-02-13 + + is debian hurd the only way to use hurd? + maybe + 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 + patches, etc...) + 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 + disappears + 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 + http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html + hm that's weird + phant0mas: what does gcc -v says and what's your host system ? + Using built-in specs. + COLLECT_GCC=gcc + + COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper + Target: x86_64-unknown-linux-gnu + Configured with: /build/gcc/src/gcc-4.8-20131219/configure + --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib + --mandir=/usr/share/man --infodir=/usr/share/info + --with-bugurl=https://bugs.archlinux.org/ + --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared + --enable-threads=posix --with-system-zlib --enable-__cxa_atexit + --disable-libunwind-exceptions --enable-clocale=gnu + --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 + --enable-install-libiberty --with-linker-hash-style=gnu + --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 + http://pastebin.com/raw.php?i=eQ75qafX + if you want to have a look as well + install gcc-multilib maybe + or lib32gcc1 + Installing gcc-multilib solves it. + braunr: it works like a charm now + phant0mas: good + + +## 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? + no idea + http://pastebin.com/raw.php?i=2HVni53Y + "creating mig" you mean ? + loot at the end of the config output + config.status: creating mig <-- + the binary + and then when you call make + it says no target + weird + 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 + http://ftp.gnu.org.ua/gnu/mig/ + version 1.4 + 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 + thnx braunr + phant0mas: mig is a shell script wrapper + so it's not a binary.... + no + + +## 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 ? + 1.4 + yes + phant0mas: just don't build scsi drivers + 1.4 + worked + why do we keep the driver if it doesn't even build ? + on debian it builds with --disable-net-group --disable-pcmcia-group + --disable-wireless-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 + a charm + 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 + hurd? + make* + 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 + http://pastebin.com/raw.php?i=4CHZJi4W + 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 + configuring/building? + tschwinge: I am trying to crossbuild it from a linux 64 bit + machine with gnu make 4.0 and gcc 4.8.2 + ../configure --prefix=/home/manolis/gnu/glibc/ + --target=i686-pc-gnu + wrong config + ../configure --prefix=/home/manolis/gnu/glibc/ + --with-headers=/home/manolis/gnu/include/ --host=i686-pc-gnu + I am using the last one + it says gnu make is too old + this time I tried with glibc from the hurd git repo + baseline branch + 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 + thnx :-) + 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'. + Stop. + 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] + __asm ("\n\ + ^ + i386/i386/i386asm.symc:116:1: error: impossible constraint in + 'asm' + http://pastebin.com/raw.php?i=emag63N4 + the config.log + and the build output if anyone want to have a look + http://pastebin.com/raw.php?i=jAZPnybB + wants* + I am building through guix so you may see some strange paths + ph4n70m4s: Nice, Guix! :-) + ph4n70m4s: Does that help? CC=gcc\ -m32 + Because: + configure:3574: gcc -v >&5 + Using built-in specs. + COLLECT_GCC=gcc + + COLLECT_LTO_WRAPPER=/nix/store/7awbhk5hdkd4lqj4wsj6lm6h84630jhm-gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper + Target: x86_64-unknown-linux-gnu + 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 + bootstrap it + and the make guix work on hurd + :-) + very cool :) + \o/ + then* + and If I manage to do all that we will be able to make a qemu + image + 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. + exaclty + 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. + I do + For example, you don't actually need to build GNU Mach + initially, but just need to install the headers/defs files + (install-data). + Perfect. + I have already done that, installing gnu mach headers was the + easy part + it's already on guix + \o/ + 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. ;-) + aaaa + :P + ph4n70m4s: Are you doing this as a Google Summer of Code + project? + I suggested the idea for the page + to ludovic + and he agreed + :-) + Good guy. + Both of you. ;-) + trying my best to help :-) + tschwinge: so to build glibc I only need mach and hurd headers + right? + yes + + +## IRC, freenode, #hurd, 2014-02-28 + + tschwinge: In your cross-gnu script while configuring hurd you + pass--disable-profile + --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 + ok + + +## 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? + yes + hrm + 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 + install-data-local-headers" ? + Does it patch the mach headers in the prefix folder? + tschwinge: why do we need this flag passed to configure at + libpthread "ac_cv_lib_ihash_hurd_ihash_create"? + 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 + the error + 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. + +[[open_issues/packaging_libpthread]]. + + 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 + Ack. + + +## IRC, freenode, #hurd, 2014-03-05 + + braunr: did i understand it correctly that our libpthread needs + libihash ? + if so, won't that be a problem for phant0mas bootstrapping + efforts ? + apparently, they're used only for thread-specific data + which could now be implemented on top of TLS + although i'm not sure + but to answer, yes, it depends on libihash + why would it be a problem ? + b/c it then forms a dependency loop + which one ? + hurd->libc (which includes libpthread, thus)->hurd + isn't that already the case ? + yes + what's the problem then ? + actually, it's not a dependency loop + y not ? + hurd and libc depend on each other headers + ah, right + actually, hurd-libs depend on libc headers + hurd executables do depend on libc + it's a bit tedious to bootstrap but not much more than the + three-step build required for linux already + actually for that libihash if I pass the flag + "ac_cv_lib_ihash_hurd_ihash_create=yes" at configure it stops asking for + it + + when glibc's configure says "configure: running configure + fragment for add-on libpthread" + does it mean it runs configure inside the folder of libpthread? + I guess so + yeh because I am getting the error configure: error: cannot + find sources (include/pthread/pthread.h) in .. or .. + which I should not as I am passing + the path to that folder + it's an error from libpthread configure + + +## IRC, freenode, #glibc, 2014-03-05 + + when we pass to the configure script of glibc the flag + --enable-add-ons=something what it the process followed for that addon? + How does it build it? + what is* + + +## IRC, freenode, #hurd, 2014-03-05 + + ../configure --without-cvs --build=i686-pc-gnu + --host=i686-pc-gnu --target=i686-pc-gnu --prefix="/home/manolis/gnu/" + --with-headers="/home/manolis/gnu/include/" --disable-profile + --disable-multi-arch --enable-add-ons=libpthread + trying to configuring glibc with libpthreads as addon I get + this + configure: running configure fragment for add-on libpthread + configure: WARNING: you should use --build, --host, --target + configure: WARNING: you should use --build, --host, --target + configure: error: cannot find sources + (include/pthread/pthread.h) in .. or .. + without libpthread it moves on + in the include folder it should find al the headers it needs + maybe it's a problem that I installed the headers from the + tarballs + while glibc is from the git repo + if I remove libpthread + I get the error configure: error: Hurd headers not installed or + too old + I really think I should reinstall the headers using the source + from the repo the headers + the headers from the tar ball are okay + when I pass this flag to "--enable-add-ons=libpthread" to glibc + configure how can I pass flags for the libpthread configure that it's + called while configuring? + phant0mas: you could look at what the debian package does + ok + phant0mas: check debian glibc for all the patches -- cgit v1.2.3