Re: glibc failing to build with undefined reference to `__vm_object_sync`

[Manolis Ragkousis]

I think we are using the latest tarball, but we will check.

On Thu, Jan 30, 2020, 19:18 Samuel Thibault  wrote:

> Efraim Flashner, le jeu. 30 janv. 2020 18:36:06 +0200, a ecrit:
> > We ran into a bug during Guix Days pre-FOSDEM where we were unable to
> > build a cross glibc for hurd.
>
> Are you using the master tree of gnumach?
>
> Samuel
>

Re: glibc failing to build with undefined reference to `__vm_object_sync`

[Manolis Ragkousis]

The version of libc we are using is the upstream glibc 2.29. No debian
patches are applied and we could not figure any that were related.

On Thu, Jan 30, 2020, 17:36 Efraim Flashner  wrote:

> We ran into a bug during Guix Days pre-FOSDEM where we were unable to
> build a cross glibc for hurd.
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

Re: hurd package

[Manolis Ragkousis]

Hello Rene

On 8/15/18 11:09 AM, Samuel Thibault wrote:
> Hello,
> 
> Rene, le mer. 15 août 2018 02:47:51 +, a ecrit:
>> I'm compiling hurd package from git 06429d67b7e9be332d1012ed4c2bba694e5ddabb 
>> through Guix and I've the following error:
>>
>> wire.c:227:9: warning: implicit declaration of function ‘vm_wire_all’ 
>> [-Wimplicit-function-declaration]
>> wire.c:227:47: error: ‘VM_WIRE_ALL’ undeclared (first use in this function)
> 
> Which version of gnumach headers are you using? The 1.8 release doesn't
> have it yet indeed, you need to use the git version.
> 



Can you try  applying this to the gnumach-headers recipe and try again?
```

diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
index d6c1fb5e6..57b9edc10 100644
--- a/gnu/packages/hurd.scm
+++ b/gnu/packages/hurd.scm
@@ -49,11 +49,14 @@
 (version "1.8")
 (source
  (origin
-  (method url-fetch)
-  (uri (gnumach-source-url version))
-  (sha256
-   (base32
-"02hygsfpd2dljl5lg1vjjg9pizi9jyxd4aiiqzjshz6jax62jm9f"
+   (method git-fetch)
+   (uri (git-reference
+ (url "git://git.sv.gnu.org/hurd/gnumach.git")
+ (commit "b25b78f5c087bd187889dc4bb6bfeff0826a651d")))
+   (sha256
+(base32
+ "1cr39r37yhnfpsrhc952rfi31bb4rrxzc6r08p2d19559yp01lxk"))
+   (file-name (string-append name "-" version
 (build-system gnu-build-system)
 (arguments
  `(#:phases
@@ -61,7 +64,10 @@
  (replace 'install
(lambda _
  (invoke "make" "install-data")))
- (delete 'build))
+ (delete 'build)
+ (add-after 'unpack 'autoreconf
+   (lambda _
+ (invoke "autoreconf" "-vif"

   ;; GNU Mach supports only IA32 currently, so cheat so that we can at
   ;; least install its headers.
@@ -72,6 +78,10 @@
 '(#:configure-flags '("--build=i586-pc-gnu")))

   #:tests? #f))
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("libtool" ,libtool)))
 (home-page
"https://www.gnu.org/software/hurd/microkernel/mach/gnumach.html;)
 (synopsis "GNU Mach kernel headers")
 (description

```
Manolis

Re: Fwd: The GNU C Library version 2.28 is now available

[Manolis Ragkousis]

On 08/01/18 18:37, Samuel Thibault wrote:
> About glibc repositories, we should upgrade the Hurd glibc repository to
> 2.28, when would that be fine for people using it? (I'm thinking about
> Guix & Arch people)
> 
> Samuel
> 

This is really great!! I will update our glibc-hurd package and we will
now probably be able to remove a lot of Hurd specific parts.

This is awesome work!!

Manolis

Re: Upstreaming the glibc Hurd port

[Manolis Ragkousis]

Hello,

On 01/19/18 12:10, Thomas Schwinge wrote:
> Beware that this script is from many years ago -- from times before my
> dear CodeSourcery colleagues taught be how to ;-) properly build
> cross-compilers.  But yes, cross-gnu did work back then.
> 
> Another thing to look into nowadays is David's (CCed) gnuxc,
> <87r3vaw4os.fsf@gmail.com">http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
> a Hurd distro",  "GNU OS Cross-Compiler".
> (I have not yet looked into that one myself.)
> 
> And, the Guix/Hurd effort also is capable of cross-compilation, as far as
> I remember.  But probably cross-gnu/gnuxc will already give you enough
> pointers of what needs to be done.
> 

Guix should be able to cross-build the hurdish glibc with custom source
with `guix build --target=i586-pc-gnu glibc-hurd --with-source=glibc.tar.gz`

Manolis

Re: boot the Hurd with Guix

[Manolis Ragkousis]

Hello Rene :D

On 11/27/17 21:05, ren...@openmailbox.org wrote:
> Hello,
> 
> This is the demo generated with Guix:
> 
> https://github.com/methalo/boot-hurd
> 
> The binary files were generated in Debian/Hurd and placed in an 'img' file.
> 
> The command used to generate the binaries is:
> 
> './pre-inst-env guix system init ~/light.scm /guix'
> 
> To test Hurd, execute:
> 
> 'sudo qemu-system-i386 -enable-kvm -m 1G -hda guixsdhurd.img -curses'
> 
> I hope to upload the patches soon to github, for now I need to understand 
> Guix/Guile to create the patches properly.
> 
> Comments and help is welcome.
> 

The repo has only a Readme file. I think you forgot to add the rest of
the files :P

Keep up the awesome work!!

Manolis

Re: boot the Hurd with Guix

[Manolis Ragkousis]

Hello everyone,

On 11/16/2017 12:13 PM, Ludovic Courtès wrote:
> Hi Samuel,  :-)
> 
> Samuel Thibault  skribis:
> 
>> Ludovic Courtès, on lun. 13 nov. 2017 11:42:01 +0100, wrote:
>>> PS: guix-daemon no longer depends on ‘lsof’, but it still depends on /proc.
>>
>> Does our procfs have everything it needs already?
> 
> It needs /proc/PID/{exe,cwd,fd,maps,environ}:
> 
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/nix/scripts/list-runtime-roots.in
> 
> That said, it’s quite optional: the worst that can happen if one of
> these things is missing is that something can be reclaimed “prematurely”
> from /gnu/store.  I say “prematurely” with quotes because users are
> supposed to register “real” GC roots anyway, as with ‘guix package -i’
> or ‘guix build --root’.

That reminds me, Rene have you tried running 'guix gc -C' ? What is the
output? Because I have a problem with this on Guix on Hurd and I haven't
managed to fix it yet.

Re: boot the Hurd with Guix

[Manolis Ragkousis]

This is awesome Rene!! Have you uploaded your changes anywhere?

On November 11, 2017 8:02:11 PM GMT+02:00, ren...@openmailbox.org wrote:
>Hola,
>
>Finally I was able to start the Hurd with the binaries generated with
>the guix package manager.
>
>At the moment the image of Hurd I have built it manually and does not
>yet have any functionality like GuixSD / Linux.
>
>Next goal:
>  * Generate the image file in the style of guix.
>** For this I have noticed that it is required to compile qemu for the
>architecture i586-pc-gnu, at the moment I could not compile qemu in
>Hurd. I have tried to disable some quemu features that come by default;
>however, I have not yet achieved it.
>
>Other pending things:
>  * Some packages fail during the compilation and testing phases.
>* Other packages used by guix, such as lsof are not ported in Hurd yet.
>
>At the moment it is everything, any doubt or help is welcome.
>
>
>Rene

Re: Question with moving mount/umount logic in glibc

[Manolis Ragkousis]

Hello Samuel, can you send me a freelink?

Thank you,
Manolis

On 04/03/2017 11:49 AM, Samuel Thibault wrote:
> Hello,
> 
> FWIW, Linux is considering to introduce another API to replace
> mount(), that will be more fd-ish, and actually more hurdish, see
> https://lwn.net/Articles/718638/ (I can provide a freelink to people
> interested, the article will be available within one week anyway).
> 
> Samuel
> 

guile 2.0.14 assertion failure

[Manolis Ragkousis]

Hello everyone,

In guile 2.0.14 while running test 00-repl-server.test with

./check-guile 00-repl-server.test

I get:

FAIL: 00-repl-server.test: repl-server: simple expression - arguments:
(expected-value "scheme@(repl-server)> $1 = 42\n" actual-value
"scheme@(repl-server)> While reading expression:\nERROR: In procedure
fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily
unavailable\nscheme@(repl-server)> While reading expression:\nERROR: In
procedure fport_fill_input: Resource temporarily unavailable\n$1 = 42\n")


Debugging it with rpctrace, it seems that the following assertion
failure causes the problem.

task192(pid5107)->mach_port_mod_refs (pn{ 46} 1 -1) = 0
  169<--197(pid5107)->io_write ("guile: ./pthread/pt-create.c:186:
__pthread_create_internal: Assertion `({ mach_" -1) = 0 225

I am attaching the rpctrace and build log. Any ideas on what is causing
this?

Manolis


svisa2w810r4i5nacqyl25zp80afg7-guile-2.0.14.drv.bz2
Description: application/bzip


rpc-trace.txt.bz2
Description: application/bzip

Re: Porting with Guix

[Manolis Ragkousis]

Hello everyone,

On 01/05/17 02:23, ren...@openmailbox.org wrote:
>  gnu/store/1h7p18gpn84kdww5i542k93arw4hhgs8-libgc-7.6.0/lib
>  make[2]: Leaving directory
> '/tmp/guix-build-libgc-7.6.0.drv-0/gc-7.6.0'
>  make  check-TESTS
>  make[2]: Entering directory
> '/tmp/guix-build-libgc-7.6.0.drv-0/gc-7.6.0'
>  make[3]: Entering directory
> '/tmp/guix-build-libgc-7.6.0.drv-0/gc-7.6.0'
>  PASS: cordtest
>  building of
> `/gnu/store/y3icscjhkk7pa7dg21xqy46riysi36rn-libgc-7.6.0.drv' timed
>  out after 3600 seconds of silence
>  @ build-failed
> /gnu/store/y3icscjhkk7pa7dg21xqy46riysi36rn-libgc-7.6.0.drv - tim
>  eout
> 

Libgc test "gctest" is entering a deadlock in version 7.6.0. The same
error does not appear in version 7.4.2 which debian/hurd uses. I am
trying to find what is causing this.

Manolis

Re: Porting with Guix

[Manolis Ragkousis]

Hello Rennes,

Please pull the latest changes from my github repo, try again and report
back.

Manolis

Re: Porting with Guix

[Manolis Ragkousis]

Hello Rennes, your previous error is becase Guix uses 4.9 as default
which doesn't support non-static initializers. I am currently rebuilding
the bootstrap-binaries so you can try again with gcc-5.

This error is probably because you are missing guile-2.0-dev.

Manolis

On 12/30/16 22:40, ren...@openmailbox.org wrote:
> Hi,
> 
> On 2016-12-30 12:19, ren...@openmailbox.org wrote:
>> Hi Manolis,
>> I updated Debian GNU/Hurd to 0.9(GNU Hurd 0.9 GNU-Mach
>> 1.8-486/Hurd-0.9 i686-AT386 GNU).
>>
>> Later, I run:
>> $ ./bootstrap
>> + exec autoreconf -vfi
>> autoreconf: Entering directory `.'
>> autoreconf: running: autopoint --force
>> autoreconf: running: aclocal --force -I m4
>> autoreconf: configure.ac: tracing
>> autoreconf: configure.ac: not using Libtool
>> autoreconf: running: /usr/bin/autoconf --force
>> configure.ac:73: error: possibly undefined macro: GUILE_MODULE_AVAILABLE
>>   If this token and others are legitimate, please use
>> m4_pattern_allow.
>>   See the Autoconf documentation.
>> autoreconf: /usr/bin/autoconf failed with exit status: 1
>>
> 
> It is posible due to the Guile version, I will return to my previuos
> version of Hurd.
> 
> Thanks

Re: Porting with Guix

[Manolis Ragkousis]

Hello Rennes,

Did you update your daemon and restart it?

Manolis

On 12/28/16 21:16, ren...@openmailbox.org wrote:
> Hi Manolis,
> 
> After successfully compiling with the new branch.
> 
> I run 'guix build hello --no-substitutes', and shows:
> 
> The following derivations will be built:
>/gnu/store/7i1nbypavdly0n0858bq9ngrhj8s5i6i-hello-2.10.drv
> 
> ...
> 
>/gnu/store/zsgpdqglj2i7i3kz777lv8kbvc9hk57h-bash-4.4.5.drv
> killing process 5040
> @ build-started
> /gnu/store/r4xnaay08x5qd8ixmzgpwzk63ylj5k87-coreutils-8.26.tar.xz.drv -
> i586-gnu
> /usr/local/var/log/guix/drvs/r4//xnaay08x5qd8ixmzgpwzk63ylj5k87-coreutils-8.26.tar.xz.drv.bz2
> 
> guix: offload: command not found
> Try `guix --help' for more information.
> killing process 5043
> guix build: error: build failed: unexpected EOF reading a line
> 
> Thanks

Re: Porting with Guix

[Manolis Ragkousis]

Sorry I forgot this.

> Are there additional changes needed compared to Guix 0.12.0?  Do you
> happen to have a write-up on how to get started with the Hurd and Guix?

Well I need to clear my daemon work and merge with guix proper. I
haven't and I need to do that.

Re: Porting with Guix

[Manolis Ragkousis]

Hey Ricardo, :-D

I don't think we have i586 binaries in Guix proper yet. We need to first
build them with hydra.

Manolis

On 12/28/16 20:15, Ricardo Wurmus wrote:
> 
> Hi Manolis,
> 
>> Now on the problem, I suppose you are using the Guix version from my
>> github repo? The wip-hurd branch is an older version which is probably
>> why you have those issues. I created a new branch in my github repo
>> called wip-hurd-native for you to clone. I cherry picked my latest
>> commits from upstream guix master and core-updates into that branch.
> 
> Are there additional changes needed compared to Guix 0.12.0?  Do you
> happen to have a write-up on how to get started with the Hurd and Guix?
> 
>> Please don't forget to place the latest guile tarball from
>> ftp://snf-656163.vm.okeanos.grnet.gr/i586-gnu/2016/ in
>> gnu/packages/bootstrap/i586-gnu as well.
> 
> Should this be changed in Guix proper?
> 

Re: Porting with Guix

[Manolis Ragkousis]

Hello Rennes,

First of all thank you for helping with this!

Now on the problem, I suppose you are using the Guix version from my
github repo? The wip-hurd branch is an older version which is probably
why you have those issues. I created a new branch in my github repo
called wip-hurd-native for you to clone. I cherry picked my latest
commits from upstream guix master and core-updates into that branch.

Please don't forget to place the latest guile tarball from
ftp://snf-656163.vm.okeanos.grnet.gr/i586-gnu/2016/ in
gnu/packages/bootstrap/i586-gnu as well.

Can you try this and report back?
Manolis

Re: Time for another round of releases

[Manolis Ragkousis]

Hello Samuel

On 11/09/16 13:54, Samuel Thibault wrote:
> Manolis Ragkousis, on Wed 09 Nov 2016 13:02:14 +0200, wrote:
>> Now I only have problems with linking http://paste.lisp.org/display/330765
> 
> __gsync_wait and __gsync_wake are gnumach RPCs. They have been added to
> gnumach quite a long time ago, don't you have them in
> gnumach/include/mach/gnumach.defs?
> 
> Samuel
> 

Yes I do have them in gnumach/include/mach/gnumach.defs.

The linking errors appears both when building from Guix and on debian/hurd.

But I have managed to bypass the linking by first running make
mach/subdir_lib, make hurd/subdir_lib, make libpthread/subdir_lib and
then make all. It seems there is an issue with the order of subdirs
building.

Manolis

Re: Time for another round of releases

[Manolis Ragkousis]

Hello Samuel,

The problem was that guix was using gcc-4.9 for cross-compiling which
has a bug not present in newer versions. Using the newer gcc-5 fixes
this. [1]

Now I only have problems with linking http://paste.lisp.org/display/330765

Has anyone encountered this before?

Thank you,
Manolis

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567

Re: Time for another round of releases

[Manolis Ragkousis]

Building the latest tschwinge/Roger_Whittaker fails with:

In file included from ../libpthread/include/pthread/pthreadtypes.h:120:0,
 from ../libpthread/include/pthread/pthread.h:55,
 from ../libpthread/include/pthread.h:2,
 from ../include/pthread.h:1,
 from ./pthread/../sysdeps/generic/pt-attr.c:20:
../libpthread/sysdeps/hurd/pt-key.h: In function ‘__pthread_key_lock_ready’:
../libpthread/sysdeps/pthread/bits/once.h:32:10: error: initializer
element is not constant
  (struct __pthread_once) { 0, __PTHREAD_SPIN_LOCK_INITIALIZER }
  ^
../libpthread/include/pthread/pthread.h:757:27: note: in expansion of
macro ‘__PTHREAD_ONCE_INIT’
 #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT
   ^
../libpthread/sysdeps/hurd/pt-key.h:55:29: note: in expansion of macro
‘PTHREAD_ONCE_INIT’
   static pthread_once_t o = PTHREAD_ONCE_INIT;
 ^

http://paste.lisp.org/display/328517

Manolis

Re: Time for another round of releases

[Manolis Ragkousis]

Hello Ludo, Hello Samuel

I am currently trying to build the latest  tschwinge/Roger_Whittaker
with Guix and it fails with

/tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:
 In function ?__register_new_task_notification?:
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:78:22:
 error: large integer implicitly truncated to unsigned type [-Werror=overflow]
   /* msgt_name = */  MACH_MSG_TYPE_POLYMORPHIC,
  ^
cc1: all warnings being treated as errors


http://paste.lisp.org/display/328211

Any ideas?

Manolis


On 10/10/16 12:15, Samuel Thibault wrote:
>
> For 2.23, the tschwinge/Roger_Whittaker is ready.
>
> Samuel



1nl08hppn6c1lpmbgw07565fbcir4f-glibc-cross-i586-pc-gnu-2.23.drv.bz2
Description: application/bzip

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

[Manolis Ragkousis]

On 08/20/16 20:47, Samuel Thibault wrote:
> Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right?

Of course :-)

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

[Manolis Ragkousis]

Hey Samuel,

Actually the Hurd part of Guix uses 2.19 as it is in
ftp://alpha.gnu.org/gnu/hurd/

The glibc tarballs use 2.19 as their version, which is the one I am
using as the version in our glibc/hurd recipe.

Check (gnu packages base) glibc/hurd.

Manolis

On 08/20/16 19:24, Samuel Thibault wrote:
> Hello,
> 
> Which glibc version is guix based on?  It's very high time we upgrade
> our glibc repository, because we see people contribute patch against
> it and it makes use rebase the work in downstreams.  I'd thus say we
> should make our glibc repository based on the minimum version used by
> the supported distros (i.e. debian & guix). Debian is currently at 2.23
> and will soon move to 2.24, a quick grep on the Guix-on-Hurd repository
> seems to be showing glibc 2.22, so we could use 2.22 for now?
> 
> Samuel
> 

[GSoC] Porting GuixSD to GNU/Hurd Update

[Manolis Ragkousis]

Hello Guix, Hello Hurd,

As GSoC is coming to an end I think it's time to sum up my work till
now, report issues I had and then talk about what our next steps are.

First I would like to mention what were the two main objectives of the
project and also what was the status of the port when the project
started, so I can give you a better understanding of the progress.

The objectives were:
1) Achieve build isolation in the daemon on the Hurd.
2) Modify Guix so it can produce a working image, while isolating any
cases of Linux assumptions.
3) Boot to GuixSD/Hurd

When the project started the guix-daemon could work on GNU/Hurd but the
builds were being affected by the system state. Normally the daemon
creates a chrooted environment to make the builds, inside /tmp, and bind
mounts the parts of the system it needs. This way it achieves isolation.

On Hurd though, because of the lack of mount(), the above could not
work. But with the help of my libhurdutil library, which I wrote at the
beginning of this project, I created 2 wrappers inside
nix/libutil/call.(hh.cc) for mount() and umount2(), called nixMount()
and nixUmount2(), and depending on the system the implementation
changes. On Hurd I am using /hurd/firmlink to offer the same
functionality to bind-mounts.

It seems to work but I am testing it thoroughly so we don't have any
unpleasant surprises in the future. We will have fully isolated builds
on Hurd as soon as I am sure that my code works as expected and it's
merged in Guix upstream.

Now on the GuixSD side, I will start on a big issue I had. If you check
the daemon, and specifically nix/libstore/build.cc:2205-2228, you will
see that when, for example, guix tries to create a 32 bit vm/image from
a 64 bit machine, the daemon actually builds the 32 bit binaries on 32
bit personality mode.

As a result it is not possible to build GuixSD/Hurd vm/images from
Linux, for now. But this is not a big problem because we can do it from
Guix running on Hurd :-). The approach I used, was to add a second hard
drive on my Hurd vm, mount it, and try to directly deploy a GuixSD
system on that drive.  Currently Guix can build most of the binaries for
the system but it still needs work to actually boot into one. You can
see the result of this work on the currect core-updates (and on my
github repo for some hacky commits).

I have also created a new module called (guix build syscalls-tools)
which contains some of the code from (guix build syscalls) which will be
used by a (guix build hurd) module, which will contain call wrappers for
some Hurd libraries. This work is still in my github repo because it
needs some work.

There was one more problem that appeared after we started using
C_INCLUDE_PATH in our cross-builds. As it seems MiG needs glibc in order
to be built.  That's why for now I patch cross-mig with the
glibc-headers so I don't have to depend on the Linux ones. But I will
talk more on this in a different email.

I think that's enough for now. I avoid talking about things discussed in
other mails, but if you want please feel free to ask me :-)

To sum things up, we almost have build isolation working but GuixSD
still needs some work to become bootable. From here on I will
finish/test my guix-daemon code, and then I will continue on finishing
the low-level call wrappers for the Hurd libraries, in order to get the
bootable system. We are close :-).

The repos which you can check any code not yet in upstream Guix or Hurd are:
https://github.com/Phant0mas/Guix-on-Hurd
https://github.com/Phant0mas/Hurd

I think that's it for now. I want to thank all of you for your help and
support and for answering my questions, and thank my two mentors Justus
and Ludo for their invaluable help (you guys are awesome :-)).

I would also like to state that thanks to the latest work from the Hurd
guys on Gnumach and Hurd, debian/hurd is more stable than ever!!

I am sure I forgot some things so feel free to ask anything or correct
me. :-)

Thank you,
Manolis

[GSoC] Porting GuixSD to GNU/Hurd Update 1

[Manolis Ragkousis]

Hello everyone,

One week passed since the beginning of the coding phase of GSoC, so I
think it's time to give you an update on my progress.

In the previous weeks I tried to get me prepared as much as possible and
get a better idea of what needs to be done.  I concentrated on getting
familiar with the parts of Guix and Hurd that are more relevant to this
project and I found out some interesting things.

We already knew that the guix-daemon was not working properly on the
Hurd.  I looked more into it and I found that if you do a build with
Guix and it fails, and then you retry again, the next one will create a
new build directory in /tmp/ as it should, but it will still use the
first one.  What this means is that the status of the previous build
leaks into the new one and there is no isolation.  With this in mind
build isolation in the daemon is currently my first priority.

I also found out that guix publish may sometimes crash if a client asks
for a big substitute.  I will investigate this one as soon as possible.

Now on the coding part, in Guix I updated the gnumach/mig/hurd packages
to the latest version and worked on getting wip-hurd in a state which
can eventually merge to master.  A part of wip-hurd is already on master
and after this core-updates cycle is merged to master, we will be able
to get the rest of wip-hurd merged as well. Package glibc/hurd will also
be updated then as well.

On debian/hurd I am using Guix every day and in my github wip-hurd I
have some patches which I need to clean up and apply to the Guix repo.
These patches are for various packages of various importance.

And on the Hurd side, I created a new library called libhurdutil and
moved the settrans implementation there.  For implementation info please
read this email[1]. I am currently improving that library after
Guillem's and Justus' input. (Thank you :-))  On the Guix side I will
just write a wrapper to use this call and we will be able to control
translators really easily.  This way the non existing mount() is not a
problem anymore :-).

I think that's enough for now.  If you have any questions/suggestions
please feel free to tell me. :-)

Thank you,
Manolis

[1]https://lists.gnu.org/archive/html/bug-hurd/2016-05/msg00041.html

[PATCH] libhurdutil: New library containing utils to be used by Guix.

[Manolis Ragkousis]

Hello everyone,

This is the library Justus suggested some time ago and it contains the
implementation of settrans. This patch actually does three things.

1) It creates libhurdutil/hurdutil.h which exposes the interface and a
struct called settrans_flags_t which contains all the flags to be used
by settrans.
2) It creates libhurdutil/settrans.c which includes the c implementation
of utils/settrans.c without the arguments parsing.
3) It modifies utils/settrans.c to use the new library. The arguments
parsing of the settrans binary happens here.

Whoever uses the library directly will modify the flags accordingly and
pass them to settrans() from the library.

In order to use it you first have to declare a variable settrans_flags_t
flags, initialize it with settrans_flags_create(), change the
flags inside settrans_flags_t, pass it to settrans() and when you are
done call settrans_flags_cleanup(flags).

I have tested it and it works. I am currently using it in my vm. But I
have some questions.

Implementation questions:
1) How should I handle errors of settrans inside the library? Normally
utils/settrans.c used error() to report any problems. But settrans()
should return error_t codes. Should I define a list of errors for
settrans() and use them accordingly? (e.g TRANS_NOT_SET etc.)
2) Do you agree with the way I handle arguments? Should I do it in a
different way?

Code indentations questions:
1) I am using emacs and I have configured it to automatically indent
code according to the gnu style. But I noticed that this causes changes
from the original. For example in the original, some '{'  are not being
tabbed 4 spaces to the right. Why? Is this a special case?

This is my first serious c library so I am sure there will be many
things that need to be changed. settrans_flags_cleanup() needs some work
and I need to add more comments. It's still work in progress so please
feel free to correct/suggest anything. :-)

Thank you,
Manolis

From 4fe21e255e483a711f898227b90b130afd969b33 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis <manolis...@gmail.com>
Date: Thu, 12 May 2016 15:08:36 +0300
Subject: [PATCH] libhurdutil: New library containing utils to be used by Guix.

* libhurdutil/hurdutil.h: New file.
* libhurdutil/settrans.c: New file.
* libhurdutil/Makefile: New file.
* utils/Makefile (HURDLIBS, settrans): Use the new library.
* utils/settrans.c: Update to use the new library.
* Makefile: (lib-subdirs): Add library.
---
 Makefile   |   2 +-
 libhurdutil/Makefile   |  28 +++
 libhurdutil/hurdutil.h |  78 +++
 libhurdutil/settrans.c | 377 ++
 utils/Makefile |   4 +-
 utils/settrans.c   | 536 ++---
 6 files changed, 633 insertions(+), 392 deletions(-)
 create mode 100644 libhurdutil/Makefile
 create mode 100644 libhurdutil/hurdutil.h
 create mode 100644 libhurdutil/settrans.c

diff --git a/Makefile b/Makefile
index d48baaa..e712767 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ include ./Makeconf
 lib-subdirs = libshouldbeinlibc libihash libiohelp libports libthreads \
 	  libpager libfshelp libdiskfs libtrivfs libps \
 	  libnetfs libpipe libstore libhurdbugaddr libftpconn libcons \
-	  libhurd-slab
+	  libhurd-slab libhurdutil
 
 # Hurd programs
 prog-subdirs = auth proc exec term \
diff --git a/libhurdutil/Makefile b/libhurdutil/Makefile
new file mode 100644
index 000..2e0e642
--- /dev/null
+++ b/libhurdutil/Makefile
@@ -0,0 +1,28 @@
+#   Copyright (C) 2016 Free Software Foundation, Inc.
+#
+#   This file is part of the GNU Hurd.
+#
+#   The GNU Hurd is free software; you can redistribute it and/or
+#   modify it under the terms of the GNU General Public License as
+#   published by the Free Software Foundation; either version 2, or (at
+#   your option) any later version.
+#
+#   The GNU Hurd is distributed in the hope that it will be useful, but
+#   WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#   General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program; if not, write to the Free Software
+#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+dir := libhurdutil
+makemode := library
+
+libname := libhurdutil
+SRCS = settrans.c
+installhdrs = hurdutil.h
+
+OBJS = $(SRCS:.c=.o)
+
+include ../Makeconf
diff --git a/libhurdutil/hurdutil.h b/libhurdutil/hurdutil.h
new file mode 100644
index 000..5786cff
--- /dev/null
+++ b/libhurdutil/hurdutil.h
@@ -0,0 +1,78 @@
+/* hurdutil.h - Hurd utils interface.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+   Written by Manolis Fragkiskos Ragkousis <manolis...@gmail.com>.
+
+   This file is part of the GNU Hurd.
+
+   The GNU Hurd is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Pu

Re: [GSoC] Porting GuixSD to GNU Hurd draft

[Manolis Ragkousis]

Hey

On 03/24/16 15:22, Ludovic Courtès wrote:
> So, let’s say PID isolation will be optional, and we can always adjust
> later on.  Sounds good?
> 
> Manolis, make sure to read about how the various Hurd servers provides
> these parts of POSIX personality: file systems, UIDs, PIDs, networking,
> and so on.

Already started. :-)

> As far as code integration code, I think we won’t bother syncing this
> work with nix-daemon; guix-daemon has already diverged, and for instance
> it does not have OS X sandbox support.
> 
> You’ll have to arrange to have the Hurd-specific bits in a separate
> file, so that ‘#ifdef HURD’ are not scattered all over the place.
> 
> This is C(++) as you know.  WDYT, Manolis?

I have to start studying the daemon's code more. From what I know the
part that handles builds is in libstore/build.cc. I will start there.

I think I can do it.

>>> The main question is whether you should implement build isolation in
>>> guix-daemon, in which case that would leave little time for the GuixSD
>>> parts.  I think I would rather let you focus on the GuixSD stuff as you
>>> wrote, but I’d like to hear what the Hurd folks think.
>>
>> I consider isolation more important.
> 
> OK.

Isolation first it is then.

> So, Manolis, what about reframing the agenda such that porting
> guix-daemon to GNU/Hurd comes first (I’d consider it roughly half of the
> programming effort), followed by GuixSD stuff?
> 

Current objectives then:
1) Achieve build isolation in the daemon on the Hurd.
2) Modify Guix so it can produce a working image, while isolating any
cases of Linux assumptions.
3) Boot to GuixSD

Ludo, Justus do you agree with this?

Manolis

Re: [GSoC] Porting GuixSD to GNU Hurd draft

[Manolis Ragkousis]

On 03/24/16 13:38, Justus Winter wrote:
> Otoh if we could properly build packages, we could provide the
> substitutes, so people could try Guix on the Hurd without going
> through the 12h+ bootstrap procedure.

Here the problem is not isolation but the fact that we don't have a
substitutes server.  The machine I had at my house crashed and I cannot
bring it back up remotely. When I get back to my home island and revive
it, this will not be an issue.

> Here is an overview of the early server bootstrap in the Hurd.  It is
> slightly outdated, but still the best description that I know of:
> 
> http://teythoon.cryptobitch.de/posts/bootstrapping-the-hurd/
>

It definitely is!! Nice one!!

> Hmmm, so one still needs a filesystem, right?  That's going to be a
> bit tricky too, since whatever tool you use for that purpose, it
> surely does not support creating hurdish passive translator records.
> Without passive translator records things get indeed more interesting.
> I have a patch for some tool for creating ext2 filesystems that could
> help, or we create all the passive translator records on first boot
> similar to how Samuels Debian/Hurd live cds deal with that.  Or I
> finish my bootshell work that can boot from filesystems without
> passive translator records.

Where can I find more info on those?

Manolis

Re: [GSoC] Porting GuixSD to GNU Hurd draft

[Manolis Ragkousis]

Hello Justus, Hello Ludo

On 03/23/16 18:55, Justus Winter wrote:
> Quoting Ludovic Courtès (2016-03-23 14:40:38)
>>> 2. The Project
>>>
>>> The project consists of four main stages
>>>
>>> 1. Modify Guix so it will be able to create and mount the file-system 
>>> needed to boot into a system with Hurd at its core. 
>>> 2. Modify Guix so it can produce a working image, while isolating any cases 
>>> of Linux assumptions.
>>> 3. Successfully boot into one such system using GNU Shepherd with pid 1.
>>> 4. Modify the new Guix system to take advantage of Hurd specific mechanisms.
> 
> For me, 4. is the most important bit, so we can build packages in
> isolation.

I think our priority should be to first get GuixSD working and then
concentrate to achieving isolation.  From what I understand none of the
two is trivial but in the long run the ability to spawn GNU/Hurd system
vms on the fly will make it easier to work on it.

>>> Currently the tools Guix uses to interact with the filesystem exist inside 
>>> the (guix build syscalls) module. 
>>> This module provides bindings to libc's syscall wrappers, which are only 
>>> available on a GNU/Linux system. 
>>> In order to offer the same functionality on a GNU/Hurd system we must first 
>>> write Guile bindings for the 
>>> relevant Hurd functions, like 'file_set_translator' in hurd/fs.defs
>>> for example.
>>
>> Note that technically the ‘file_set_translator’ function is in libc:
>>
>> --8<---cut here---start->8---
>> scheme@(guile-user)> (dynamic-func "file_set_translator" (dynamic-link))
>> $1 = #
>> --8<---cut here---end--->8---
>>
>>> This module will be called (guix build hurd). This allows us to
>>> re-implement the functionality of the 'settrans' command, as described
>>> here[1], in Scheme and use that in place of 'mount()', where
>>> applicable.
> 
> Right.  In fact, what settrans (or mount) does isn't that hard to
> reproduce, though I wouldn't mind moving the c implementation to
> libhurdutil or the like and binding to that.

Then I think it will be wiser to move the c implementation of settrans
to libhurdutil and binding to that.  Then we will only need a (guix
build hurd) module which will include that binding.  I will update the
proposal if you agree.

>> I think it’s important to think about:
>>
>>   1. How functionality equivalent to linux-{initrd,boot} will be
>>  implemented on the Hurd.
>>
>>  In my experience the equivalent thing is simpler on the Hurd,
>>  esp. if relying on passive translators (see daemons/runsystem.sh in
>>  the Hurd), though here we’ll probably explicitly activate
>>  translators at boot time.
> 
> Currently, there is not really a reason to have an initrd-like
> solution on the Hurd.  Yes, one has to start the default pager
> explicitly, but that's about it.

Then it seems we only need a hurd-boot module which will take care of
activating translators and booting the system.

>   2. How to structure GuixSD code in a way that abstracts the
> underlying OS kernel.
>
>  For instance, we could have a (guix build os) module providing an
>  API that works for both kernels, probably close to the Linux one,
>  and that would dispatch to the right implementation, the Linux or
>  Hurd one.

This module sounds like a great idea. I will add it to the proposal.


>>> Finally, once GuixSD is successfully ported, we can cater to the last stage 
>>> of taking advantage of Hurd specific 
>>> mechanisms. 
>>> This includes but is not limited to:
>>> 1)Replacing (gnu build linux-container) with (gnu build subhurd) when on a 
>>> GNU/Hurd system. Subhurds can offer 
>>> isolation similar to Linux containers as described here[3].
>>
>> This is really super optional IMO.  This module is only used by ‘guix
>> environment --container’, which is an optional feature.
> 
> Yes, subhurds are more on the experimental side imho.

So Adding subhurd support -> if there is time.
> 
>>> 2)Modify the guix-daemon to run without root privileges by utilizing the 
>>> Hurd architecture. The daemon needs root 
>>> privileges in order to setup chrooted environments for the builds.  In the 
>>> Hurd this can be done by setting up a 
>>> translator as described here[4]. 
>>
>> This is more important, and already non-trivial work.  If libc provided
>> ‘mount’ with support for MS_BIND (which I think it should), it would
>> help a bit, but there’s still the problem of the other Linux name spaces
>> that are used (the CLONE_NEW* clone(2) flags.)
>>
>> Thus it may make more sense to write this functionality in guix-daemon
>> using directly the Hurd interfaces.  Separate PID name spaces, UID name
>> spaces, mount name spaces, etc. are fairly natural on the Hurd: it’s
>> “just” a matter of giving the child process ports to separate proc,
>> auth, etc. translators.
>>
>> In itself this is also a bit of work.  I wonder what the Hurd folks
>> think about priorities here?

Re: GSoC ideas

[Manolis Ragkousis]

Hey

On 03/02/16 23:31, Ludovic Courtès wrote:
> Do you have examples of GNU/Linux uses that would make no sense?
> 

After a quick look in mount's man page I think that maybe Roland was
referring to some flags (like relatime for example) that when passed to
mount, expect the Linux kernel to handle the filesystem in a specific way.

> Other options include calling out to the ‘settrans’ command (inelegant
> IMO), writing Guile bindings for some of the Hurd libraries, and/or some
> sort of a MiG in Scheme (neat but takes some time!).

We could have a guile wrapper for the ‘settrans’ command that could
cover our needs. Isn't this feasible? WDYT?

Manolis

Re: [gscriv...@gnu.org: [IMPORTANT] Ideas for Summer of Code 2016]

[Manolis Ragkousis]

Hey

On Feb 14, 2016 12:40 PM, "Justus Winter" <4win...@informatik.uni-hamburg.de>
wrote:
> *
https://www.gnu.org/software/hurd/community/gsoc/project_ideas/package_manager.html
>
> This talks about replacing Guix symlink-tree with a specialized
> translator.

That would be a nice addition.

Manolis

Re: GSoC ideas

[Manolis Ragkousis]

Hello everyone,

As I am still a student I would like to suggest continuing the project
of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
having a working GuixSD/Hurd by the end of the summer.

After discussions with Justus and Samuel in FOSDEM about the Guix-Hurd
port I am starting to have a good idea on what is left to be done and
the solution needed for the problems we have.

So here's a preliminary timeline as well as a list of things to be done:

Before May:

1) Merge wip-hurd branch.
2) Make the daemon handle chroot builds on the Hurd.
Note here that on the Hurd, one does not need to be root to achieve
isolation, so I should change the daemon to use this capability.
3) Instead of using the Linux syscall guile wrappers, I should modify
Guix to use a more Hurdish way (i.e settrans) so later on we can handle
translators and bootstrap a GNU/Hurd system.
4) Better understand how GuixSD startup works.

May-August:
1) Implement the mechanisms for creating and mounting the initial
filesystem and starting the system.
2) Implement the mechanisms to handle the Hurd servers in /hurd. I
remember I was told that there may be an issue when the servers are not
actually there (i.e all the binaries are in the /gnu/store). Would love
if somebody could tell us more on that.
3) Isolate Linuxisms around Guix.
4) David Michael has made an excelent work on getting Shepherd working
with Hurd so I don't think we will have any serious issues with the init
daemon.
5) Others that will come up.. In the following weeks I will work closely
with the Hurd guys to make sure we get a better understanding of
everything and a detailed timeline.

End of GSoC:
Have a working GuixSD with Hurd as the kernel.

Currently Justus (and others soon :-)) are testing Guix on their
machines. We have some issues but we are working on them.

Please feel free to add/correct anything from the above. Your
comment/opinion may help to get things up and running faster :-)

Finally I want to say that I will continue my work on this, regardless
of GSoC or not, but I would like it if it was. :-)

Thank you,
Manolis

Re: fosdem talk?

[Manolis Ragkousis]

Well the bulk of the work has been done and Guix does run on Hurd.

It is still ongoing but now I am mostly solving per package problems and
eliminating Linuxism in Guix now but I am not sure if this is enough for
another gsoc. We can talk about it tomorrow.

Btw Samuel I have a talk tomorrow at 10:50 about my GSoC work. Any Hurd
guy/girl available at that time please come. :)

Manolis

P.S. excuse me if this mail contains any html, I am sending it from my
smartphone.

Re: Rolling new releases

[Manolis Ragkousis]

There is also a patch in the debian glibc called
"unsubmitted-clock_t_centiseconds.diff" that fixes some test failures
for programs like guile.

Could this patch be included as well, if a new glibc+libpthread
snapshot is created?

Thanks,
Manolis

[PATCH] Check sysheaders when looking for Mach and Hurd headers

[Manolis Ragkousis]

Hello everyone,

With this patch, glibc's configure takes into account the
"--with-headers" argument
when checking for Mach and Hurd header.

This patch applies on glibc master.
From 163cac91f3e5d8e200cf2ddd4a44fe582b989f48 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis <manolis...@gmail.com>
Date: Wed, 26 Aug 2015 23:48:33 +0200
Subject: [PATCH] Check sysheaders when looking for Mach and Hurd headers

* sysdeps/mach/configure.ac: Add sysheaders check.
* sysdeps/mach/configure: Regenerate.
* sysdeps/mach/hurd/configure.ac: Add sysheaders check.
* sysdeps/mach/hurd/configure: Regenerate.
---
 sysdeps/mach/configure | 9 +
 sysdeps/mach/configure.ac  | 9 +
 sysdeps/mach/hurd/configure| 9 +
 sysdeps/mach/hurd/configure.ac | 9 +
 4 files changed, 36 insertions(+)

diff --git a/sysdeps/mach/configure b/sysdeps/mach/configure
index 228f99e..4d2a4e3 100644
--- a/sysdeps/mach/configure
+++ b/sysdeps/mach/configure
@@ -165,6 +165,11 @@ fi
 config_vars="$config_vars
 MIG = $MIG"
 
+if test -n "$sysheaders"; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS="$CPPFLAGS $SYSINCLUDES"
+fi
+
 ### Sanity checks for Mach header installation
 
 
@@ -553,3 +558,7 @@ if test $hurd_cv_mig_retcode = yes; then
   $as_echo "#define HAVE_MIG_RETCODE 1" >>confdefs.h
 
 fi
+
+if test -n "$sysheaders"; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
diff --git a/sysdeps/mach/configure.ac b/sysdeps/mach/configure.ac
index db85f47..00b660c 100644
--- a/sysdeps/mach/configure.ac
+++ b/sysdeps/mach/configure.ac
@@ -6,6 +6,11 @@ if test "x$MIG" = xMISSING; then
 fi
 LIBC_CONFIG_VAR([MIG], [$MIG])
 
+if test -n "$sysheaders"; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS="$CPPFLAGS $SYSINCLUDES"
+fi
+
 ### Sanity checks for Mach header installation
 AC_CHECK_HEADER(mach/mach_types.h,,
 [AC_MSG_ERROR([cannot find Mach headers])], -)
@@ -124,3 +129,7 @@ if test $hurd_cv_mig_retcode = yes; then
 fi])
 
 hurd_MIG_RETCODE
+
+if test -n "$sysheaders"; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
diff --git a/sysdeps/mach/hurd/configure b/sysdeps/mach/hurd/configure
index 4248758..3d155a4 100644
--- a/sysdeps/mach/hurd/configure
+++ b/sysdeps/mach/hurd/configure
@@ -3,6 +3,11 @@
 $as_echo "#define NO_HIDDEN 1" >>confdefs.h
 
 
+if test -n "$sysheaders"; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS="$CPPFLAGS $SYSINCLUDES"
+fi
+
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking Hurd header version" >&5
 $as_echo_n "checking Hurd header version... " >&6; }
@@ -36,3 +41,7 @@ $as_echo "$libc_cv_hurd_version" >&6; }
 if test "x$libc_cv_hurd_version" != xok; then
   as_fn_error $? "Hurd headers not installed or too old" "$LINENO" 5
 fi
+
+if test -n "$sysheaders"; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
diff --git a/sysdeps/mach/hurd/configure.ac b/sysdeps/mach/hurd/configure.ac
index b1f16a5..af9a9ea 100644
--- a/sysdeps/mach/hurd/configure.ac
+++ b/sysdeps/mach/hurd/configure.ac
@@ -3,6 +3,11 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
 dnl We need this setting because of the need for PLT calls in ld.so.
 AC_DEFINE([NO_HIDDEN])
 
+if test -n "$sysheaders"; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS="$CPPFLAGS $SYSINCLUDES"
+fi
+
 AC_CACHE_CHECK(Hurd header version, libc_cv_hurd_version, [dnl
 AC_TRY_COMPILE(dnl
 [#include ], [
@@ -15,3 +20,7 @@ AC_TRY_COMPILE(dnl
 if test "x$libc_cv_hurd_version" != xok; then
   AC_MSG_ERROR(Hurd headers not installed or too old)
 fi
+
+if test -n "$sysheaders"; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
-- 
2.5.1

Re: [PATCH] Check sysheaders when looking for Mach and Hurd headers.

[Manolis Ragkousis]

On 27 August 2015 at 00:44, Samuel Thibault samuel.thiba...@gnu.org wrote:
 Please do, the patch looks completely sane (and is actually what other
 configure.ac files do).

Will do :)

Re: AC_NO_EXECUTABLES

[Manolis Ragkousis]

On 19 August 2015 at 20:06, Samuel Thibault samuel.thiba...@gnu.org wrote:
 I'll see around that, but it'd be more convenient that ac_no_link makes
 link test fail only, not abort...

That sounds great. :)

Manolis

[PATCH] Check sysheaders when looking for Mach and Hurd headers.

[Manolis Ragkousis]

Hello everyone,

With this patch, glibc's configure, when checking for Mach and Hurd
headers, takes
into account the --with-headers argument.

I am not sending this to libc-alpha because I noticed there are some
differences in the
files I am patching and the patch won't apply there. I will send to
libc-alpha an updated
patch that applies to their tree.
From 39b09d8cb8ee3b3ca0ca9fcd772df3fab41c02f8 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis manolis...@gmail.com
Date: Fri, 14 Aug 2015 01:20:59 +0300
Subject: [PATCH] Check sysheaders when looking for Mach and Hurd headers.

* sysdeps/mach/configure.ac: Add sysheaders check.
* sysdeps/mach/configure: Regenerate.
* sysdeps/mach/hurd/configure.ac: Add sysheaders check.
* sysdeps/mach/hurd/configure: Regenerate.
---
 sysdeps/mach/configure | 9 +
 sysdeps/mach/configure.ac  | 9 +
 sysdeps/mach/hurd/configure| 9 +
 sysdeps/mach/hurd/configure.ac | 9 +
 4 files changed, 36 insertions(+)

diff --git a/sysdeps/mach/configure b/sysdeps/mach/configure
index 290a5ff..d7c102c 100644
--- a/sysdeps/mach/configure
+++ b/sysdeps/mach/configure
@@ -165,6 +165,11 @@ fi
 config_vars=$config_vars
 MIG = $MIG
 
+if test -n $sysheaders; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS=$CPPFLAGS $SYSINCLUDES
+fi
+
 ### Sanity checks for Mach header installation
 
 
@@ -553,3 +558,7 @@ if test $hurd_cv_mig_retcode = yes; then
   $as_echo #define HAVE_MIG_RETCODE 1 confdefs.h
 
 fi
+
+if test -n $sysheaders; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
diff --git a/sysdeps/mach/configure.ac b/sysdeps/mach/configure.ac
index 52d47e0..f972270 100644
--- a/sysdeps/mach/configure.ac
+++ b/sysdeps/mach/configure.ac
@@ -6,6 +6,11 @@ if test x$MIG = xMISSING; then
 fi
 LIBC_CONFIG_VAR([MIG], [$MIG])
 
+if test -n $sysheaders; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS=$CPPFLAGS $SYSINCLUDES
+fi
+
 ### Sanity checks for Mach header installation
 AC_CHECK_HEADER(mach/mach_types.h,,
 [AC_MSG_ERROR([cannot find Mach headers])], -)
@@ -124,3 +129,7 @@ if test $hurd_cv_mig_retcode = yes; then
 fi])
 
 hurd_MIG_RETCODE
+
+if test -n $sysheaders; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
diff --git a/sysdeps/mach/hurd/configure b/sysdeps/mach/hurd/configure
index a0f9721..4b2ad37 100644
--- a/sysdeps/mach/hurd/configure
+++ b/sysdeps/mach/hurd/configure
@@ -17,6 +17,11 @@ case $machine in
 ;;
 esac
 
+if test -n $sysheaders; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS=$CPPFLAGS $SYSINCLUDES
+fi
+
 
 { $as_echo $as_me:${as_lineno-$LINENO}: checking Hurd header version 5
 $as_echo_n checking Hurd header version...  6; }
@@ -50,3 +55,7 @@ $as_echo $libc_cv_hurd_version 6; }
 if test x$libc_cv_hurd_version != xok; then
   as_fn_error $? Hurd headers not installed or too old $LINENO 5
 fi
+
+if test -n $sysheaders; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
diff --git a/sysdeps/mach/hurd/configure.ac b/sysdeps/mach/hurd/configure.ac
index ad915a5..db783a0 100644
--- a/sysdeps/mach/hurd/configure.ac
+++ b/sysdeps/mach/hurd/configure.ac
@@ -17,6 +17,11 @@ case $machine in
 ;;
 esac
 
+if test -n $sysheaders; then
+  OLD_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS=$CPPFLAGS $SYSINCLUDES
+fi
+
 AC_CACHE_CHECK(Hurd header version, libc_cv_hurd_version, [dnl
 AC_TRY_COMPILE(dnl
 [#include hurd/version.h], [
@@ -29,3 +34,7 @@ AC_TRY_COMPILE(dnl
 if test x$libc_cv_hurd_version != xok; then
   AC_MSG_ERROR(Hurd headers not installed or too old)
 fi
+
+if test -n $sysheaders; then
+  CPPFLAGS=$OLD_CPPFLAGS
+fi
-- 
2.5.0

Problem with natively built binaries on Hurd from Guix

[Manolis Ragkousis]

Hello guys,

I asked the same question yesterday in the irc, but I thought I
should repost it to the mailing list so more people can see it.

When I try to run the binaries, I get error while loading shared
libraries: libmachuser.so.1: cannot open shared object file: No
such file or directory

libmachuser.so.1 does exist in the expected path and trying to
run a binary with LD_LIBRARY_PATH=/gnu/store/...-glibc-bootstrap-0/lib ./a.out
works.

The output of 'objdump -x
/gnu/store/...-glibc-bootstrap-0/lib/libc.so.0.3 |grep RUNPATH'
does not return anything, while the output of objdump -x
/gnu/store...-glibc-bootstrap-0/lib/libc.so.3 | grep NEED
returns:
  NEEDED   ld.so.1
  NEEDED   libmachuser.so.1
  NEEDED   libhurduser.so.0.3
  VERNEED  0x00016054
  VERNEEDNUM   0x0001

The problem is that  libc.so depends on lib*user.so, but doesn't
have them in its RUNPATH. But if we change the RUNPATH of
libc.so,  ld.so complains and fails if libc.so's RUNPATH is non-empty.

What can we do? How can we solve this?

Manolis

Question with moving mount/umount logic in glibc

[Manolis Ragkousis]

Hello everyone,

Time for glibc questions :)

I have a question about utils/mount.c. In the contribution page it says
Move the mount/umount logic from utils/{,u}mount.c into glibc.

After a short conversation with Thomas here 's how I think I will implement it :

(glibc)/sysdeps/mach/hurd/mount.h : Declarations of mount, umount,
umount2  and possible
flags as described in
http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html
and compared to [glibc]/sysdeps/unix/sysv/linux/sys/mount.h, so we can
stay compatibile at the API level
with other systems.

(glibc)/sysdeps/mach/hurd/mount.hc: Mount/umount implementation. In
other words move the
implementation from hurd to glibc.

(hurd)/utils/mount.c: A util which will use the glibc mount
implementation to do the same work as before.

And here are a few things I have to keep an eye on, which Thomas pointed out.
1) After the change, existing older Hurd binaries should still work
fine, and with the changed
[hurd]/utils/mount.c
2) The mount interface provided by glibc need to be just enough to
stay compatibile at the API level
which is what we want in Guix.

WDYT? Please feel free to comment/suggest. :-)

Manolis

Re: [GSoC] Guix + Hurd continuation

[Manolis Ragkousis]

Hello everyone,

On 2 July 2015 at 12:12, Ludovic Courtès l...@gnu.org wrote:
   0. Run Guix’s ‘./configure --with-courage  make’ and see what
  happens.
   1. ‘guix-daemon’ must work correctly on GNU/Hurd.

Already started working on them. Will report back today on my first results.


   2. When building natively, surely you’ll find out that some packages
  do not build (PATH_MAX!), and that there are assumptions in
  hurd.scm and base.scm, such as the fact that GNU/Hurd is a
  cross-compilation target and not a native system.

I already have a pretty solid idea of what you mean. Will work around
them as I progress.

   3. In parallel to that, I should review wip-hurd again and apply the
  patches to a new ‘core-updates’ branch.

Okay.

   4. Instead of sitting idle watching build logs ;-), it Would Be Nice™
  to implement the ‘mount’ and ‘umount’ functions for GNU/Hurd in
  libc, with support for MS_BIND using /hurd/firmlink.
  Of course libc hacking can be quite involved.  So ideally Samuel,
  Thomas, and others would give you detailed guidance and/or hack
  power.  What do people think?

Yes,  I think now it's the right time to start this. Expect questions
as I work on this. :-)
Meanwhile if the hurd guys have something to point out, please do. :-)

 Another can of worms I forgot to mention is hurd/paths.h, which
 assumes that translators live in /hurd, whereas we’ll rather have them
 in /gnu/store/…/hurd.

A question. Isn't it possible, that this will break the Hurd expected
behavior? I think I should get
a better understanding of how things work.

Manolis

Re: glibc build log (TLS-related issue)

[Manolis Ragkousis]

On 23 June 2015 at 16:10, Samuel Thibault samuel.thiba...@gnu.org wrote:
 Ok, the change which made my glibc work with static linking is:

 --host=i586-gnu --build=i586-gnu

 I guess the default i686 variant introduces bugs.


Trying to run make lib in darnassus using i586-gnu, with the debian
sources, fails with

/home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
function `__strcspn_sse42':
(.text.sse4.2+0x1d73): undefined reference to `__strcspn_ia32'
/home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
function `__strpbrk_sse42':
(.text.sse4.2+0x1eb0): undefined reference to `__strpbrk_ia32'
/home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
function `__strspn_sse42':
(.text.sse4.2+0x1fe8): undefined reference to `__strspn_ia32'
collect2: error: ld returned 1 exit status

and the same command with the tarballs sources end up with

http://paste.lisp.org/display/150437

Any ideas?

Re: glibc build log (TLS-related issue)

[Manolis Ragkousis]

On 23 June 2015 at 16:10, Samuel Thibault samuel.thiba...@gnu.org wrote:
 Ok, the change which made my glibc work with static linking is:

 --host=i586-gnu --build=i586-gnu

 I guess the default i686 variant introduces bugs.


Trying to run make lib in darnassus using i586-gnu, with the debian
sources, fails with

/home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
function `__strcspn_sse42':
(.text.sse4.2+0x1d73): undefined reference to `__strcspn_ia32'
/home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
function `__strpbrk_sse42':
(.text.sse4.2+0x1eb0): undefined reference to `__strpbrk_ia32'
/home/phant0mas/sources/debian-glibc/glibc-2.19/build/libc_pic.os: In
function `__strspn_sse42':
(.text.sse4.2+0x1fe8): undefined reference to `__strspn_ia32'
collect2: error: ld returned 1 exit status

and the same command with the tarballs sources end up with

http://paste.lisp.org/display/150437

Any ideas?

Re: glibc build log (TLS-related issue)

[Manolis Ragkousis]

Hi again

On 24 June 2015 at 12:17, Thomas Schwinge tho...@codesourcery.com wrote:
 and the same command with the tarballs sources end up with

 http://paste.lisp.org/display/150437

 That looks like https://sourceware.org/PR15605,
 http://news.gmane.org/find-root.php?message_id=%3CE1VU3KH-00083u-04%40vasks.debian.org%3E,
 http://news.gmane.org/find-root.php?message_id=%3CE1VU9tp-0007UR-IS%40vasks.debian.org%3E.

Applied unsubmitted-NO_HIDDEN.diff, in the tarball source, built with
-enable-add-ons=libpthread --enable-pt_chown --disable-nscd
CFLAGS=-O2 --host=i586-gnu --build=i586-gnu
and I got a working static binary :-D

Now time to do the same with Guix.

Manolis

Re: glibc build log (TLS-related issue)

[Manolis Ragkousis]

On 24 June 2015 at 12:17, Thomas Schwinge tho...@codesourcery.com wrote:
 That looks like something's going wrong with IFUNCs,
 http://www.gnu.org/software/hurd/open_issues/ifunc.html.  What's your
 exact configure command line?  In particular, are you using
 --disable-multi-arch (if I remember correctly)?

No I am not. I am using ../configure --prefix=/
--enable-add-ons=libpthread --enable-pt_chown --disable-nscd
CFLAGS=-O2 --host=i586-gnu --build=i586-gnu

Re: GSoC: Porting Guix to Hurd week 3+4 report.

[Manolis Ragkousis]

Hello Thomas

Actually I did a mistake last time, I should have told you to build gcc-4.8,
not gcc-4.7, because that's what make-bootstrap.scm use.

Btw I managed to build the bootstrap-tarballs. Per Ludo's suggestion I removed
--disable-decimal-float flag from %gcc-static and we got the binaries. :-)

 Did that.

 From there:

   git clone git://git.savannah.gnu.org/guix.git

 (Per Manolis' suggestion, I'm using his GitHub repository.)

I am cleaning up my local patches so we can just use wip-hurd from Savannah.

   cd guix
   git checkout wip-hurd
   guix environment guix

 (Very pedantically, is that last commant completely correct?  My
 understanding is that it sets up an environment for building the version
 of the guix package that is current known to Guix, and not the version
 From the checkout of the wip-hurd branch.  Of course, the underlying
 assumption must be that these two versions have the same dependencies, so
 their environment setup will be the same.)

You are correct, these two versions have the same dependencies, so
their environment setup will be the same.


   autoreconf  ./configure --localstatedir=/var \
 --with-libgcrypt-prefix=/gnu/store/...  make

 (Not relevant right now, but why is the libgcrypt path not communicated
 via the environment variables set up with guix environment?  Is that just
 because there are no appropriate environment variables, or something
 else?)  Also, I wanted to note that I, very guixy, computed that path
 using:

 $ guix build libgcrypt
 warning: failed to install locale: Invalid argument
 /gnu/store/r16v30hlw2d6n232rm37p53qy8rpr7f2-libgcrypt-1.6.3
 /gnu/store/42ls5n7k6lai1k6xfa8v8wks7nn9g3gn-libgcrypt-1.6.3-debug


It will be better if Ludo answers that.

 Next, I ran:

 $ ./pre-inst-env guix build --target=i686-pc-gnu gcc-4.7 -K -c 8

  After it fails

 ..., and eventually reproduced the problem.  However, that took a series
 of steps that was much longer that I had anticipated:

 $ ls -lrt /var/log/guix/drvs/*/*

 I have not yet made an attempt to understand all of that.  ;-)

Keep in mind that ls -lrt /var/log/guix/drvs/*/*  will show you all
the logs. You will probably
only need to check the last ones.


  go to /tmp/nix-build-gcc-4.7...  and there you can find
  the failed build. Everything will be there.

 Assuming I need to patch the GCC sources, do I just do that in
 /tmp/nix-build-gcc-4.7.4.drv-0/gcc-4.7.4/, and then, to continue the
 build, just run the same guix build command again?  (I guess I'll also
 have to preserve my changes elsewhere, as that temporary working tree
 will be removed upon a successful build?)

You will need to patch the source at gcc-4.7 in gcc.scm.To add a new patch,
first place the new patch in gnu/packages/patches/a-new-patch.patch,
then add it in gnu-system.am
in the base directory under patchdir and the add it in the source
field of the package you want.
Search for patches inside gnu/packages/ in files *.scm on how to do
that. There are plenty of examples.

 Also, in case it should be necessary to restart this build step from
 scratch, do I just remove the /tmp/nix-build-gcc-4.7.4.drv-0/build
 directory, and then run the same guix build command again?

You just rerun the same command. It will just create a new one (drv-1,
2, 3 and so on) in /tmp.
No need to delete anything.

 In case I need to modify the build instructions of an earlier build step,
 I guess I need to do this the Guix way, that is, edit the respective
 *.scm file, and re-run guix build?  Do I need to invalidate the earlier
 build, or will that happen automatically?  How do I patch the sources
 of an earlier build step, that is, rebuild a package using the same build
 instructions but with a different set of sources (say, from a local Git
 checkout)?

It will happen automatically. You patch the source of each package in the way
I described you above. If you want to change the source, you just
change the source field
of the package. Search for git-fetch in gnu/packages and you will
understand how to make it
use a remote git (I am not sure how to make it use a local repo, Ludo
please help :-)). Keep in mind
that everytime you change the source you should update the hash of
those sources. You can get the
hash of a source tarball or a git repo with guix hash.

Manolis

Re: GSoC: Porting Guix to Hurd week 3+4 report.

[Manolis Ragkousis]

Hello

 Now, from a discussion we had on IRC, I think the problem reported at
 the beginning of this thread is fixed.  Manolis, can you confirm?

Yes, I am doing a local cleanup and I am sending the patches to the list.

 Also, I think the target should be 4.9 or 4.8, but definitely not 4.7.
 See also
 http://lists.gnu.org/archive/html/guix-devel/2015-06/msg00052.html.

Yes it was a mistake from my part.

Manolis

Re: GSoC: Porting Guix to Hurd week 3+4 report.

[Manolis Ragkousis]

Hey Thomas, thank you for looking into this.

On 2 June 2015 at 18:55, Thomas Schwinge tho...@codesourcery.com wrote:
 Shame on me, but I've never actively used/built Guix before.  I do know
 about https://github.com/Phant0mas/Guix-on-Hurd, and that there must be
 a Guix manual existing -- but can you help me get started, please?
 (Pointers to specific parts of documentation are appreciated, of course.)

So let's start with the easy one. Currently Guix can be used only of top of a
GNU/Linux system. So with that in mind, clone the repo (the one from savannah
git://git.savannah.gnu.org/guix.git )
on one such system and make sure you have the dependencies mentioned at
http://www.gnu.org/software/guix/manual/guix.html#Requirements installed.
Then you just need the usual ./configure  make  make install on
the master branch to build and
install guix. After that follow
http://www.gnu.org/software/guix/manual/guix.html#Setting-Up-the-Daemon
on how to setup the builder accounts and how to run the daemon.
Congrats you are a proud user of Guix :-).

Now just checkout the wip-hurd branch from my github repo. I have some
changes there not yet present
or ready for the branch in savannah. Run make again and you are ready.


 Is there a way to have the Guix build process create a shell script (or
 some other linearized log of command invocations)?  At this point, the
 latter would be earier for me to debug (evem reproduce?), compared to
 really learning Guix -- which I'll be happy to do (and have been
 meaning to do for a looong time...), but then it's probably going to take
 longer for me to really get started.

 Alternatively/additionally, I'd also appreciate a high-level
 (coarse-grained) overview about the steps you're executing right now.
 (Maybe that already documented somewhere, or is obvious from the Guix
 build description files -- which I have not yet looked at.)  That is,
 something like: 1) install GNU Mach headers: configure [...]  make
 install [...], 2) install Hurd headers: [...], 3) build minimal cross-GCC
 configured with [...] options: [...], and so on.


Now the hard part. Ludovic if I do any mistakes on this part, please
correct me. :-)

I will mostly point you on the right places in the code to look,
because I believe the package
definitions are quite simple to understand and they will be much more
helpful in understanding
what's going on.

The command we want to use is ./pre-inst-env guix build
--target=i686-pc-gnu gcc-4.7 -K
The flag -K keeps the failed build directory in /tmp. This commands
tries to cross build gcc
for --target=i686-pc-gnu.


Let's start on how we get the cross-toolchain in gnu/packages/cross-base.scm.

The building sequence
1) Build cross-binutils for target system.
2) Build minimal cross-gcc with the flags from cross-gcc-arguments
3) Build xgnumach-headers, xmig, xhurd-headers, xglibc/hurd-headers,
xhurd-minimal and finally
cross-libc
4) Build cross-gcc with the now present cross-libc.
5) We now have a cross toolchain for our needs.

This part works as expected.
The part that is failing is the Canadian cross. That is, cross-compiling GCC.
To reproduce, in the guix directory, run ./pre-inst-env guix build
--target=i686-pc-gnu gcc-4.7 -K

gcc-4.7 package definition is located in gnu/packages/gcc.scm and the
configure flags are defined in
configure-flags in the same file. We build this packages using the
cross-toolchain from above.

After it fails go to /tmp/nix-build-gcc-4.7...  and there you can find
the failed build. Everything will be there.
As for the the logs, they can  be found with ls -ltr
/usr/local/var/log/guix/drvs/*/*.

I hope this explains most of the things on how to reproduce the error.

Thank you again for helping me on this :-)

Manolis

GSoC: Porting Guix to Hurd week 2 report

[Manolis Ragkousis]

Hello Guix, Hello Hurd

Time for the second report. Will report what happened in chronological
order like the last time.

1) I modified gnumach-headers and hurd-headers packages so they will use
--build=i686-pc-gnu only when not cross-building.

2) Mig needs flex for both build and run time. So I added flex as both an input
and a native input. Before we were getting a linking error when cross-building.

3) Flex and bison could not be built with when targeting the hurd.
This was because of the
dependency lists m4-bison-2.7-flex and m4-bison.

4) m4 for some reason would run make test even when cross-compiling.
So when hurd
was targeted (and mips as Ludovic pointed out today) it would fail. I
disabled the tests
when cross-building in my local repo and spent quite some time waiting
for the whole
rebuild to finish :P. In any case, Ludovic pushed today at master, a
patch that fixes that.

5) Tomorrow if not today I will have ready the bootstrap-tarballs. I
modified make-boostrap.scm
to use the hurd headers, and everything up to %glibc-bootstrap-tarball
builds fine. I am waiting
for the current build to finish to report on the rest.

There was a problem with the libpthread native input where
(copy-recursively (assoc-ref inputs
 libpthread) libpthread) would evaluate to (copy-recursively #f
libpthread), when creating the tarballs.
I changed it to use %build-inputs and it seemed to work, but after
Thomas uploaded the
glibc-hurd+ libpthread tarball, I removed the problematic part all together.
In any case we should still investigate this one.

6) As I said above Thomas uploaded today a glibc-hurd+ libpthread
tarball. With this, our package
definition for glibc/hurd became as simple as it could possibly get in
this form. The patches are gone.
I can sleep with ease now. Thank you Thomas :-).

I was thinking about following Mark's suggestion of having a generic
glibc package with all the common
configure flags and inputs, and the two others inheriting from it,
defining the specific sources and
inputs/flags. WDYT?

Ludovic I don't have anything to report on the binaries actually
running on hurd right now,
because I am hoping to test that with the actual bootstrap tarballs.

I think that's it for this week. If you have any questions please feel
free to ask :-)

Manolis

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

[Manolis Ragkousis]

Hello everyone,

Everything works great with those branches.
Thomas please have a look at uploading a tarball. :-)

Manolis

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

[Manolis Ragkousis]

Good morning Samuel,


 seems to be going fine.  Thomas, can you have a look at uploading a
 tarball of this so it can be used as a base for Guix?

I will try to build it as well and I'll report back.

Samuel, Thomas, thank you for working on this. :-)

Manolis

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

[Manolis Ragkousis]

Hello everyone and thank you :-)

On 29 April 2015 at 22:40, Ludovic Courtès l...@gnu.org wrote:

 Manolis, Samuel: feel free to mention whatever I forgot!


I just wanted to add that I will keep a repo at github which I will upload any
(serious) local changes before I send them as patches so anyone can keep
an eye on the current status of my work.

Here is the link: https://github.com/Phant0mas/Guix-on-Hurd

Also I was discussing with Ludovic on how to keep everybody up to date.
We thought it would be nice to have regular irc talks and once per week I
will send a report on the status of my work on both mailing lists.
WDYT Samuel?

Thank you :-)
Manolis

Re: 'struct flock' has no member named 'l_end'

[Manolis Ragkousis]

One last thing,

in libpthread commit
8b48173fdc8f52a234ff9d3d1de5277c60d7eea4 the
Makefile expects shm-directory.c to be present in
sysdeps/generic/ but it is not.

This file only exists in glibc 2.21 and is not yet
implemented in our libpthread.

Thanks you,
Manolis

Re: 'struct flock' has no member named 'l_end'

[Manolis Ragkousis]

Hello,

On 25 March 2015 at 01:39, Samuel Thibault samuel.thiba...@gnu.org wrote:
 This was not up to date to some oddness in the tls-threadvar branch, but
 I've now fixed it, and thus contains the fix from the corresponding
 branch.

Thank you.

 BTW, I think the latest libpthread source will save you some unnecessary
 burden about libpthead bits/ headers which would previously have to be
 installed before building glibc.

Thank you Samuel, this is really appreciated! Ludovic was telling me a couple
of days ago, that maybe we should consider hosting somewhere, a tar version
of glibc and libpthread with the latest updates. This will make our
lifes much easier.
WDYT?

And one more thing. In libpthread commit
44ae774bed1a75ea926590f1bc7c9f3328219832
you pushed

-#ifdef IS_IN_libpthread
+#if IS_IN (libpthread)

But it ends failing with

./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
  ^

Attaching build log.

Thank you,
Manolis
In file included from ./pthread/../sysdeps/generic/pt-attr.c:25:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
In file included from 
./pthread/../sysdeps/generic/pt-attr-getinheritsched.c:21:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
In file included from ./pthread/../sysdeps/generic/pt-attr-getschedparam.c:24:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
In file included from ./pthread/../sysdeps/generic/pt-attr-getscope.c:21:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
In file included from 
./pthread/../sysdeps/generic/pt-attr-getschedpolicy.c:21:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
In file included from 
./pthread/../sysdeps/generic/pt-attr-getdetachstate.c:21:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/sysd-rules:2439: 
recipe for target 
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-destroy.o'
 failed
make[2]: *** 
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-destroy.o]
 Error 1
make[2]: *** Waiting for unfinished jobs
/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/sysd-rules:2439: 
recipe for target 
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr.o'
 failed
make[2]: *** 
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr.o]
 Error 1
In file included from ./pthread/../sysdeps/generic/pt-attr-getguardsize.c:21:0:
./pthread/pt-internal.h:38:11: error: missing binary operator before token (
 #if IS_IN (libpthread)
   ^
/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/sysd-rules:2439: 
recipe for target 
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-getschedpolicy.o'
 failed
make[2]: *** 
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-getschedpolicy.o]
 Error 1
./pthread/pt-internal.h:63:13: error: missing binary operator before token (
 #if !(IS_IN (libpthread))
 ^
/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/sysd-rules:2439: 
recipe for target 
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-getschedparam.o'
 failed
make[2]: *** 
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-getschedparam.o]
 Error 1
/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/sysd-rules:2439: 
recipe for target 
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-getscope.o'
 failed
make[2]: *** 
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-0/build/libpthread/pt-attr-getscope.o]
 Error 1

'struct flock' has no member named 'l_end'

[Manolis Ragkousis]

Hello Samuel, Hello Hurd hackers

Glibc, branch tschwinge/Roger_Whittaker fails to build
with  'struct flock' has no member named 'l_end' .

The problem was introduced with commit
0a137670752d07827ce8612505c85f4dafb70d28 in file
sysdeps/mach/hurd/fcntl.c with

+   return __f_setlk (fd, fl-l_type, fl-l_whence,
+ fl-l_start, fl-l_end, wait);

fl is of type struct flock and it has no member named l_end.

Is there something I am missing? According to the git commit
logs, this is there since November but it causes a build failure.

Thank you for your time.
Manolis

Re: FOSDEM

[Manolis Ragkousis]

On 28 January 2015 at 15:56, Thomas Schwinge tho...@codesourcery.com wrote:

 Better late than never!  Please edit/extend
 http://darnassus.sceen.net/~hurd-web/community/meetings/fosdem_2015/.
 with your data.

Sorry, I don't have an account either. I am arriving on Friday 11:00
AM and leaving on
Monday around 12PM.

 Oh, and on Friday evening, there's a GNU dinner.  Guests are very
 welcome, of course.
 http://news.gmane.org/find-root.php?message_id=%3C87r3ufi0y9.fsf%40yamato.home%3E.

I don't think I will make it to the dinner, but count me in for a
beer. I will send you my phone number
in another (off-the-list) mail, so you can text me any plans if I am not around.

Looking forward to see you :-D,
Manolis

Re: FOSDEM talk?

[Manolis Ragkousis]

Nice idea.

I will be able to join you this year. Looking forward.

Manolis

Re: nscd fails to build

[Manolis Ragkousis]

First of all we get the error  that Ludo sent in the previous message
if we leave nscd enabled.

Now the problem is in nscd/connection.c at struct database_dyn dbs[lastdb].

The macro PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP is used,
but it's nowhere to be found in libpthread as one would expect.
Normally there should be a definition in
libpthread/include/pthread/pthread.h as is the case of
PTHREAD_MUTEX_INITIALIZER.

Should PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP be replaced
with __PTHREAD_RWLOCK_INITIALIZER which is already declared? If I do
this, there is no error.

Second question, can nscd be enabled with hurd in the first place?
Because even when I replace the macro, I get the message

 gai.c:41:22: fatal error: check_pf.c: No such file or directory
  #include check_pf.c
   ^
 compilation terminated.
 ../o-iterator.mk:9: recipe for target 
 '/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-5/build/nscd/gai.o' 
 failed

check_pf.c can be found in ./sysdeps/unix/sysv/linux/check_pf.c and
./inet/check_pf.c so I shouldn't be getting that error message.

And lastly , Samuel please push the patch Ludovic sent here
https://lists.gnu.org/archive/html/bug-hurd/2014-06/msg00108.html
about nscd in the tschwinge/Roger_Whittaker branch. It removes
conflicting ‘thread_info_t’ declaration between nscd and Mach.

Thank you for your time.
Manolis

Re: [PATCH] nscd: Remove unused typedef and variable.

[Manolis Ragkousis]

Tested on Hurd.

Manolis

Re: Circular dependency with glibc libpthread libihash

[Manolis Ragkousis]

 Could you try

 AC_MSG_WARN(cross-compiling, disabling linking)

 ?

diff --git a/configure.ac b/configure.ac
index ecabfdf..7ede6db 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,13 @@ AC_PROG_INSTALL
 AC_PROG_AWK
 AC_PROG_SED

+if test x$cross_compiling = xyes; then
+   # It may be that we don't have a working libc yet, for instance
+   # because we're bootstrapping the cross-compilation tool chain.
+   # Thus, use this undocumented Autoconf macro designed for this.
+   AC_NO_EXECUTABLES
+   AC_MSG_WARN(cross-compiling, disabling linking)
+fi
 AC_PROG_CC
 # Require GCC.
 if test x$GCC != xyes; then

Works like a charm.

Manolis

State of patch in debian/hurd glibc

[Manolis Ragkousis]

What is the state of the patch unsubmitted-pthread_posix-option.diff
from the debian/hurd glibc package?
It is critical in building glibc, as without it fails with

  In file included from gai_sigqueue.c:22:0:
  ./gai_misc.h:32:5: error: unknown type name 'pthread_cond_t'
   pthread_cond_t *cond;
   ^
  ./gai_misc.h:74:1: error: unknown type name 'pthread_mutex_t'
   extern pthread_mutex_t __gai_requests_mutex;

Also if I don't patch Versions.def file with

--- a/Versions.def
+++ b/Versions.def
@@ -102,6 +102,7 @@ libpthread {
   GLIBC_2.6
   GLIBC_2.11
   GLIBC_2.12
+  GLIBC_2.17
   GLIBC_PRIVATE
 }
 libresolv {

 will fail with
  version GLIBC_2.17 not defined for libpthread

Maybe some of these changes should be pushed to upstream.What do you think?
Even if glibc doesn't have an integrated pthread library, it depends on the hurd
packages which have a pthread library, so we should provide all the defines etc.

Avoid letting glibc try to install its own headers for libpthread.

No topgit branch, TODO?

---
 sysdeps/mach/hurd/Makefile |4 +++
 sysdeps/mach/hurd/bits/posix_opt.h |   40 ++---
 sysdeps/mach/hurd/gai_misc.h   |   44 +
 3 files changed, 75 insertions(+), 13 deletions(-)

--- a/sysdeps/mach/hurd/bits/posix_opt.h
+++ b/sysdeps/mach/hurd/bits/posix_opt.h
@@ -71,24 +71,38 @@
 /* XPG4.2 shared memory is supported.  */
 #define _XOPEN_SHM  1
 
-/* We do not have the POSIX threads interface.  */
-#define _POSIX_THREADS -1
+/* Tell we have POSIX threads.  */
+#define _POSIX_THREADS 200112L
 
 /* We have the reentrant functions described in POSIX.  */
 #define _POSIX_REENTRANT_FUNCTIONS  1
 #define _POSIX_THREAD_SAFE_FUNCTIONS   200809L
 
-/* These are all things that won't be supported when _POSIX_THREADS is not.  */
+/* We do not provide priority scheduling for threads.  */
 #define _POSIX_THREAD_PRIORITY_SCHEDULING  -1
-#define _POSIX_THREAD_ATTR_STACKSIZE   -1
-#define _POSIX_THREAD_ATTR_STACKADDR   -1
+
+/* We support user-defined stack sizes.  */
+#define _POSIX_THREAD_ATTR_STACKSIZE   200112L
+
+/* We support user-defined stacks.  */
+#define _POSIX_THREAD_ATTR_STACKADDR   200112L
+
+/* We do not support priority inheritence.  */
 #define _POSIX_THREAD_PRIO_INHERIT -1
+
+/* We do not support priority protection.  */
 #define _POSIX_THREAD_PRIO_PROTECT -1
+
 #ifdef __USE_XOPEN2K8
+/* We do not support priority inheritence for robust mutexes.  */
 # define _POSIX_THREAD_ROBUST_PRIO_INHERIT -1
+
+/* We do not support priority protection for robust mutexes.  */
 # define _POSIX_THREAD_ROBUST_PRIO_PROTECT -1
 #endif
-#define _POSIX_SEMAPHORES  -1
+
+/* We support POSIX.1b semaphores.  */
+#define _POSIX_SEMAPHORES  200112L
 
 /* Real-time signals are not yet supported.  */
 #define _POSIX_REALTIME_SIGNALS-1
@@ -121,17 +135,17 @@
 /* GNU libc provides regular expression handling.  */
 #define _POSIX_REGEXP  1
 
-/* Reader/Writer locks are not available.  */
-#define _POSIX_READER_WRITER_LOCKS -1
+/* Reader/Writer locks are available.  */
+#define _POSIX_READER_WRITER_LOCKS 200112L
 
 /* We have a POSIX shell.  */
 #define _POSIX_SHELL   1
 
-/* We cannot support the Timeouts option without _POSIX_THREADS.  */
-#define _POSIX_TIMEOUTS-1
+/* We support the Timeouts option.  */
+#define _POSIX_TIMEOUTS200112L
 
-/* We do not support spinlocks.  */
-#define _POSIX_SPIN_LOCKS  -1
+/* We support spinlocks.  */
+#define _POSIX_SPIN_LOCKS  200112L
 
 /* The `spawn' function family is supported.  */
 #define _POSIX_SPAWN   200809L
@@ -140,7 +154,7 @@
 #define _POSIX_TIMERS  0
 
 /* The barrier functions are not available.  */
-#define _POSIX_BARRIERS-1
+#define _POSIX_BARRIERS200112L
 
 /* POSIX message queues could be available in future.  */
 #define_POSIX_MESSAGE_PASSING  0
--- a/sysdeps/mach/hurd/Makefile
+++ b/sysdeps/mach/hurd/Makefile
@@ -167,6 +167,10 @@
 CFLAGS-dl-load.c = -DEXTERNAL_MAP_FROM_FD
 endif
 
+ifeq ($(subdir),posix)
+CFLAGS-confstr.c += -DLIBPTHREAD_VERSION='libpthread 0.3'
+endif
+
 # Override the generic Makeconfig values so we link against the RPC libs.
 link-libc-static := -Wl,--start-group \
$(patsubst %,$(common-objpfx)%.a,\
--- /dev/null
+++ b/sysdeps/mach/hurd/gai_misc.h
@@ -0,0 +1,44 @@
+#include signal.h
+#include pthread.h
+
+#define gai_start_notify_thread __gai_start_notify_thread
+#define gai_create_helper_thread __gai_create_helper_thread
+
+extern inline void
+__gai_start_notify_thread (void)
+{
+  sigset_t ss;
+  sigemptyset (ss);
+  sigprocmask(SIG_SETMASK, ss, NULL);
+}
+
+extern inline int
+__gai_create_helper_thread (pthread_t *threadp, void *(*tf) (void *),
+   void *arg)
+{
+  pthread_attr_t attr;
+
+  /* Make sure the thread is created detached.  */
+  pthread_attr_init 

Re: State of patch in debian/hurd glibc

[Manolis Ragkousis]

That's great thank you :-)

Manolis

Re: Circular dependency with glibc libpthread libihash

[Manolis Ragkousis]

 Could you try this patch for the Hurd’s configure.in?

I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail with
 syntax error near unexpected token `fi'.

Re: Circular dependency with glibc libpthread libihash

[Manolis Ragkousis]

I sent the mail by mistake incomplete, I am sorry.

 Could you try this patch for the Hurd’s configure.in?

I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail with
 syntax error near unexpected token `fi'.
Other than that it works as expected for me.

diff --git a/configure.ac b/configure.ac
index ecabfdf..7ede6db 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,13 @@ AC_PROG_INSTALL
 AC_PROG_AWK
 AC_PROG_SED

+if test x$cross_compiling = xyes; then
+   # It may be that we don't have a working libc yet, for instance
+   # because we're bootstrapping the cross-compilation tool chain.
+   # Thus, use this undocumented Autoconf macro designed for this.
+   AC_NO_EXECUTABLES
+   echo done
+fi
 AC_PROG_CC
 # Require GCC.
 if test x$GCC != xyes; then

Manolis

Problem with glibc and libihash

[Manolis Ragkousis]

First of all libihash and any of the hurd libraries cannot be built
without a working glibc. Hurd libs depend heavily on header files
found in glibc like lowlevellock.h, so even after making the build
system of the hurd repository to accept not to be able to build
programs (as Samuel suggested), we are still not able to build the
libs.

So our only option is to build a glibc without the libpthread addon,
use it to build libihash, and then rebuild glibc with libpthread. But
theres comes our second and biggest problem.

Glibc cannot be built without libpthread.

If you try to do it, you will get the error message:

In file included from hurdsig.c:23:0:
../include/pthread.h:1:26: fatal error: pthread.h: No such file or directory
 #include_next pthread.h
  ^
compilation terminated.
../o-iterator.mk:9: recipe for target 
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.19.drv-2/build/hurd/hurdsig.o' 
failed
make[2]: *** 
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.19.drv-2/build/hurd/hurdsig.o] 
Error 1
make[2]: *** Waiting for unfinished jobs

which pthread.h is a header file from libpthread in sysdeps/generic/bits/ .
So my question is, shouldn't the glibc be able to be built without
this addon? Is glibc building procedure broken?

Re: Circular dependency with glibc libpthread libihash

[Manolis Ragkousis]

0:00 Ludovic Courtès l...@gnu.org:

 Could you show what test tries to compile a program?  (Send config.log.)


Here it is
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU Hurd configure 0.5, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ../source/configure 
CONFIG_SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
--prefix=/gnu/store/qsyxfd97vcy5fq2hkq5r2gaq5zidjpi7-hurd-minimal-cross-i686-pc-gnu-0.5
 --enable-fast-install --host=i686-pc-gnu --without-parted

## - ##
## Platform. ##
## - ##

hostname = localhost
uname -m = x86_64
uname -r = 3.13.6-1-ARCH
uname -s = Linux
uname -v = #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: 
/gnu/store/kavylb2khfqq9rj42diyciinv3i8inj4-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/bin
PATH: 
/gnu/store/nkrr16lw55p75483z2an0c67nnqdm4l5-binutils-cross-i686-pc-gnu-2.23.2/bin
PATH: /gnu/store/144wbw5kmmwnxd57zr5q274sx4pa52kd-mig-cross-1.4/bin
PATH: /gnu/store/1i1jcl43kcs9v0g962sj5s70igxy2g2g-autoconf-2.69/bin
PATH: /gnu/store/f4v605p9fva9kjragznh3l28nfpzmcqp-tar-1.27.1/bin
PATH: /gnu/store/7267cq3clzcbgd1k7s5rg0i0vp2yklpl-gzip-1.6/bin
PATH: /gnu/store/a1ir9y0bgaazp6n58y3qbhmfymjq3yxq-bzip2-1.0.6/bin
PATH: /gnu/store/1zs7xnaby6vl49195sid1klx3gk03mwd-xz-5.0.4/bin
PATH: /gnu/store/2ly72pfnmg28ps7jdj83516gvbn6371j-diffutils-3.3/bin
PATH: /gnu/store/1qdk13ly4c5iqqz7nay0x4fn6ls5r1b9-patch-2.7.1/bin
PATH: /gnu/store/gjl05yl9lvgjhznz5v985mys861svp34-coreutils-8.21/bin
PATH: /gnu/store/sj5ivydxwm1943y2g06vhwfwpn9hc1a1-sed-4.2.2/bin
PATH: /gnu/store/v2q2595q6n4gs32j15ga65bgy0yqg76g-grep-2.15/bin
PATH: /gnu/store/r534qbhj6jni2x30q4rgl8ry8rilarak-findutils-4.4.2/bin
PATH: /gnu/store/3j4pxqg9rskk9365m6jqi59pvcyq1d82-gawk-4.1.0/bin
PATH: /gnu/store/pwm61di9kpfks4acn0k6kp2rwa0wjl5j-make-4.0/bin
PATH: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin
PATH: /gnu/store/r7lpkp8d2df74rw24ndcivxvjzdgxn8d-ld-wrapper-0/bin
PATH: /gnu/store/xbryfykc21adgrq3z56g4c6xvv2lb645-binutils-2.23.2/bin
PATH: /gnu/store/z8qifq9172ad17a7mxg9w8jq51axwwqr-gcc-4.8.2/bin
PATH: /gnu/store/5v11czsqd9x9xqvsww9dk7h5i47laym0-glibc-2.18/bin
PATH: /gnu/store/5v11czsqd9x9xqvsww9dk7h5i47laym0-glibc-2.18/sbin


## --- ##
## Core tests. ##
## --- ##

configure:2245: checking build system type
configure:2259: result: x86_64-unknown-linux-gnu
configure:2279: checking host system type
configure:2292: result: i686-pc-gnu
configure:2402: checking for a BSD-compatible install
configure:2470: result: 
/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
/tmp/nix-build-hurd-minimal-cross-i686-pc-gnu-0.5.drv-0/source/install-sh -c -C
configure:2485: checking for gawk
configure:2501: found 
/gnu/store/3j4pxqg9rskk9365m6jqi59pvcyq1d82-gawk-4.1.0/bin/gawk
configure:2512: result: gawk
configure:2523: checking for a sed that does not truncate output
configure:2587: result: 
/gnu/store/sj5ivydxwm1943y2g06vhwfwpn9hc1a1-sed-4.2.2/bin/sed
configure:2601: checking for i686-pc-gnu-gcc
configure:2617: found 
/gnu/store/kavylb2khfqq9rj42diyciinv3i8inj4-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/bin/i686-pc-gnu-gcc
configure:2628: result: i686-pc-gnu-gcc
configure:2897: checking for C compiler version
configure:2906: i686-pc-gnu-gcc --version 5
i686-pc-gnu-gcc (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2917: $? = 0
configure:2906: i686-pc-gnu-gcc -v 5
Using built-in specs.
COLLECT_GCC=i686-pc-gnu-gcc
COLLECT_LTO_WRAPPER=/gnu/store/kavylb2khfqq9rj42diyciinv3i8inj4-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/4.8.2/lto-wrapper
Target: i686-pc-gnu
Configured with: 
Thread model: single
gcc version 4.8.2 (GCC) 
configure:2917: $? = 0
configure:2906: i686-pc-gnu-gcc -V 5
i686-pc-gnu-gcc: error: unrecognized command line option '-V'
i686-pc-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2917: $? = 1
configure:2906: i686-pc-gnu-gcc -qversion 5
i686-pc-gnu-gcc: error: unrecognized command line option '-qversion'
i686-pc-gnu-gcc: fatal error: no input files
compilation terminated.
configure:2917: $? = 1
configure:2937: checking whether the C compiler works
configure:2959: i686-pc-gnu-gccconftest.c  5
/gnu/store/kavylb2khfqq9rj42diyciinv3i8inj4-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
 cannot find crt1.o: No such file or directory

Circular dependency with glibc libpthread libihash

[Manolis Ragkousis]

When libpthread tries to link against libihash.so I get the error:

/lib/libihash.so: file not recognized: File format not recognized.

This happens because libihash was built using the native compiler.
So I changed the flag in libihash configure to --host so it will use
the cross-compiler. But then I got the error configure:3008: error: C
compiler cannot create executables.
I read the config.log file and the problem arise from this
/../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
cannot find crt1.o: No such file or directory
/../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
cannot find crti.o: No such file or directory
/../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
cannot find -lc
/../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
cannot find crtn.o: No such file or directory

It tries to compile a program, but cannot find these files, so it
fails. But in order to have them we need glibc.

We have a circular dependency glibc+libpthread - libihash - glibc,
so I guess an intermediate glibc is our only option. Or is there
another way?

Re: Glibc building procedure error report.

[Manolis Ragkousis]

I am having some problems with building the libpthread addon. I get the error

  ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: 
 '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function)
   #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER  -- but I 
 can't seem to find this
^
  ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:46:33: note: in expansion of 
 macro '_HURD_THREADVAR_THREAD'
__hurd_threadvar_location (_HURD_THREADVAR_THREAD);\
  ^
  ./pthread/../sysdeps/generic/pt-barrier-wait.c:52:32: note: in expansion of 
 macro '_pthread_self'
 struct __pthread *self = _pthread_self ();

I searched the source files for the macros
'_HURD_THREADVAR_DYNAMIC_USER' and '_HURD_THREADVAR_THREAD' and I
can't seem to find them so where are they used? I noticed
'_HURD_THREADVAR_DYNAMIC_USER' used to be in /hurd/hurd/threadvar.h
but now it's removed.

Any ideas?

Re: Glibc building procedure error report.

[Manolis Ragkousis]

2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org:
 Which version of libpthread is this? I don't have this in my copy of the
 tree.  We got rid of these a long time ago.

I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44

Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff

[Manolis Ragkousis]

As I said in the irc it would be really helpfull if the debian patches
got merged with the upstream. Right now whenever I get an error, I am
searching in them, handpicking the part that solves it. Actually some
of the debian patches are necessary to built glibc and libpthread. I
will report exactly which parts I needed from which patches, as soon
as possible, so I can help Justus merge them.

Manolis

Re: Glibc building procedure error report.

[Manolis Ragkousis]

 However, it adds the start/stop symbols for the hurd_fork hooks, but not
 for the hurd_atfork hooks.  Do we need something like this:

I added the following lines to the shlib.lds part of Makerules so I
can bypass the problem and it seems to work.

+PROVIDE(__start__hurd_atfork_prepare_hook = .);\
+_hurd_atfork_prepare_hook : { *(_hurd_atfork_prepare_hook) }\
+PROVIDE(__stop__hurd_atfork_prepare_hook = .);\
+PROVIDE(__start__hurd_atfork_child_hook = .);\
+_hurd_atfork_child_hook : { *(_hurd_atfork_child_hook) }\
+PROVIDE(__stop__hurd_atfork_child_hook = .);\
+PROVIDE(__start__hurd_atfork_parent_hook = .);\
+_hurd_atfork_parent_hook : { *(_hurd_atfork_parent_hook) }\
+PROVIDE(__stop__hurd_atfork_parent_hook = .);\

Re: Glibc building procedure error report.

[Manolis Ragkousis]

  Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should
  have made the build system take the libpthread/sysdeps path into account
  (at least in the Debian package it does).

It takes into account the libpthread/sysdeps tree path. I have pasted
the corresponding output of the configure script in the link below.
  http://paste.debian.net/plain/91552
The error appears when we include bits/(filename).h. It just looks
for the headers in the bits/ folder, while they are at
libpthread/sysdeps/generic/bits/.

   A workaround is to add lines in Makerules just like there are for 
 *__libc_thread_subfreeres

There are already lines in Makerules for that.

   PROVIDE(__start__hurd_fork_parent_hook = .);\
   _hurd_fork_parent_hook : { *(_hurd_fork_parent_hook) }\

I am investigating if everything works as it should in my environment.

I have attached the output of the configure part of the building
process, so you can have a better look.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-gnu
checking for i686-pc-gnu-gcc... i686-pc-gnu-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-gnu-gcc accepts -g... yes
checking for gcc... gcc
checking for i686-pc-gnu-g++... no
checking for i686-pc-gnu-c++... no
checking for i686-pc-gnu-gpp... no
checking for i686-pc-gnu-aCC... no
checking for i686-pc-gnu-CC... no
checking for i686-pc-gnu-cxx... no
checking for i686-pc-gnu-cc++... no
checking for i686-pc-gnu-cl.exe... no
checking for i686-pc-gnu-FCC... no
checking for i686-pc-gnu-KCC... no
checking for i686-pc-gnu-RCC... no
checking for i686-pc-gnu-xlC_r... no
checking for i686-pc-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for i686-pc-gnu-readelf... i686-pc-gnu-readelf
checking for sysdeps preconfigure fragments... x86_64 
configure: running configure fragment for add-on libidn
configure: running configure fragment for add-on libpthread
configure: running configure fragment for add-on nptl
checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm hppa 
ia64 m68k microblaze mips tile 
checking for assembler and linker STT_GNU_IFUNC support... yes
checking whether .text pseudo-op must be used... yes
checking sysdep dirs... libpthread/sysdeps/mach/hurd/i386 
sysdeps/mach/hurd/i386 libpthread/sysdeps/mach/hurd libpthread/sysdeps/hurd 
sysdeps/mach/hurd sysdeps/gnu sysdeps/unix/bsd/bsd4.4 sysdeps/mach/i386 
libpthread/sysdeps/mach sysdeps/mach sysdeps/i386/i686/fpu sysdeps/i386/i686 
sysdeps/i386/i486 sysdeps/i386/fpu sysdeps/x86/fpu libpthread/sysdeps/i386 
sysdeps/i386 sysdeps/x86 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-96 
sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/unix/bsd 
sysdeps/unix/inet sysdeps/ieee754 sysdeps/unix sysdeps/posix 
libpthread/sysdeps/posix sysdeps/generic
configure: WARNING: add-on ports contributed no sysdeps directories
checking for a BSD-compatible install... 
/gnu/store/gjl05yl9lvgjhznz5v985mys861svp34-coreutils-8.21/bin/install -c
checking whether ln -s works... yes
checking whether 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as
 is GNU as... yes
checking whether 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld
 is GNU ld... yes
checking for 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as...
 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as
checking version of 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as...
 2.23.2, ok
checking for 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld...
 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld
checking version of 
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld...
 2.23.2, ok
checking for i686-pc-gnu-gcc... (cached) i686-pc-gnu-gcc
checking version of i686-pc-gnu-gcc... 4.8.2, ok
checking for gnumake... no
checking for gmake... no
checking for make... make
checking version of make... 4.0, ok
checking for gnumsgfmt... no
checking for gmsgfmt... no
checking for msgfmt... no
checking for makeinfo... no
checking for sed... sed
checking version of sed... 4.2.2, ok
checking for gawk... gawk
checking version of gawk... 4.1.0, ok
checking for i686-pc-gnu-nm... i686-pc-gnu-nm
checking for autoconf... autoconf
checking whether autoconf works... yes
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt 
makeinfo
*** some features will be disabled.
*** Check the INSTALL file for 

Re: Glibc building procedure error report.

[Manolis Ragkousis]

As I said in the irc I managed to bypass the previous error by
deleting #define _EXTERN_INLINE in signal/sigsetops.c

I am now getting the error

  /../build/libc_pic.os: In function `__fork':
  /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to 
 `__start__hurd_atfork_prepare_hook'
  /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: 
 /../build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden   
 symbol `__start__hurd_atfork_prepare_hook' can not be used when making a 
 shared object
  /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: final 
 link failed: Bad value
  collect2: error: ld returned 1 exit status
  ../Makerules:614: recipe for target '/../build/libc.so' failed
  make[2]: *** 
 [/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/build/libc.so] Error 
 1
  make[2]: Leaving directory 
 '/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/source/elf'
  Makefile:233: recipe for target 'elf/subdir_lib' failed

I searched the source files in posix and sysdeps/mach/hurd/ and I
can't seem to find any reference to
`__start__hurd_atfork_prepare_hook'.

Any ideas?

Manolis

Glibc building procedure error report.

[Manolis Ragkousis]

I came across on some issues in the building procedure which are not solved
in the debian patches so I think I should report them, ask for comments on
them and be as solid as possible in my descriptions.

First there are 2 definitions of sigset_t

One in (path_to_glibc)/libpthread/signal/signal.h

  typedef uint64_t sigset_t;

and one in (path_to_glibc)/misc/sys/select.h

  typedef __sigset_t sigset_t;

The build procedure fails if I don't comment one of them out.

Secondly the building procedure was looking for the header files located in
(path_to_glibc)/libpthread/sysdeps/generic/bits in the
(path_to_glibc)/bits so I had to copy them there manually.

And finally I get the error collect2: error: ld returned 1 exit status in
this part here

  make[4]: Entering directory '/../source/hurd'
  /../build/libc_pic.a(sigsetops.os): In function `__spin_unlock':
  /../source/signal/../sysdeps/mach/i386/machine-lock.h:44: multiple
definition of `__spin_unlock'

/../build/libc_pic.a(spin-lock.os):/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/i386/machine-lock.h:44:
first defined here

  /../build/libc_pic.a(sigsetops.os): In function `__spin_try_lock':
  /../source/signal/../sysdeps/mach/i386/machine-lock.h:59: multiple
definition of `__spin_try_lock'

/../build/libc_pic.a(spin-lock.os):/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/i386/machine-lock.h:59:
first defined here

  /../build/libc_pic.a(sigsetops.os): In function `__spin_lock_locked':
  /../source/signal/../sysdeps/mach/i386/machine-lock.h:74: multiple
definition of `__spin_lock_locked'

/../build/libc_pic.a(spin-lock.os):/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/i386/machine-lock.h:74:
first defined here
  collect2: error: ld returned 1 exit status
  ../Makerules:589: recipe for target '/../build/libc_pic.os' failed
  make[2]: ***
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/build/libc_pic.os]
Error 1

I am working on solving this last one, but I would like any possible help.

Manolis

Re: libpthread fails to build as an add-on

[Manolis Ragkousis]

As Ludovic wrote

  Actually libc's configure doesn't use the normal AC_CONFIG_SUBDIRS
  mechanism, and instead runs add-on configure scripts by itself, without
  arguments AFAICS.

The part responsible for this is in the attached file and specifically the
part:
  libc_add_on_frag=$libc_add_on_srcdir/configure

I was thinking of modifying the configure script so it would use the
AC_CONFIG_SUBDIRS mechanism and configure all the addons with the flags
passed in the glibc configure.
Then I would apply the patch in a patch-phase before configure gets called
in guix.
What do you think?

Manolis
  # Now source each add-on's configure fragment.
  # The fragments can use $srcdir/$libc_add_on to find themselves,
  # and test $add_ons_automatic to see if they were explicitly requested.
  # A fragment can clear (or even change) $libc_add_on to affect
  # whether it goes into the list to be actually used in the build.
  use_add_ons=
  for libc_add_on in $add_ons; do
# Test whether such a directory really exists.
# It can be absolute, or relative to $srcdir, or relative to the build dir.
case $libc_add_on in
/*)
  libc_add_on_srcdir=$libc_add_on
  ;;
*)
  test -d $srcdir/$libc_add_on || {
if test -d $libc_add_on; then
  libc_add_on=`pwd`/$libc_add_on
else
  as_fn_error $? add-on directory \$libc_add_on\ does not exist 
$LINENO 5
fi
  }
  libc_add_on_srcdir=$srcdir/$libc_add_on
  ;;
esac

libc_add_on_frag=$libc_add_on_srcdir/configure 
libc_add_on_canonical=
libc_add_on_config_subdirs=
if test -r $libc_add_on_frag; then
  { $as_echo $as_me:${as_lineno-$LINENO}: running configure fragment for 
add-on $libc_add_on 5
$as_echo $as_me: running configure fragment for add-on $libc_add_on 6;}
  libc_add_on_canonical=unknown
  libc_add_on_subdirs=
  . $libc_add_on_frag
  test -z $libc_add_on || {
configured_add_ons=$configured_add_ons $libc_add_on
if test x$libc_add_on_canonical = xunknown; then
  as_fn_error $? fragment must set \$libc_add_on_canonical $LINENO 5
fi
for d in $libc_add_on_subdirs; do
  case $libc_add_on in
  /*) subdir_srcdir=$libc_add_on ;;
  *) subdir_srcdir=\$(..)$libc_add_on ;;
  esac
  case $d in
  .)
d=${libc_add_on_canonical:-$libc_add_on}
;;
  /*)
subdir_srcdir=$d
;;
  *)
subdir_srcdir=$subdir_srcdir/$d
;;
  esac
  d=`echo $d | sed 's@/*$@@;s@^.*/@@'`
  add_on_subdirs=$add_on_subdirs $d
  test $subdir_srcdir = \$(..)$d || config_vars=$config_vars
$d-srcdir = $subdir_srcdir
done
for d in $libc_add_on_config_subdirs; do
  case $d in
  /*) as_fn_error $? fragment uses absolute path in 
\$libc_add_on_config_subdirs $LINENO 5 ;;
  esac
  if test ! -d $libc_add_on_srcdir/$d; then
as_fn_error $? fragment wants to configure missing directory $d 
$LINENO 5
  fi
  case $libc_add_on in
  /*) as_fn_error $? relative path required for add-on using 
\$libc_add_on_config_subdirs $LINENO 5 ;;
  esac
  subdirs=$subdirs $libc_add_on/$d
done
  }
fi
if test -n $libc_add_on; then
  if frags=`ls -d $libc_add_on_srcdir/sysdeps/*/preconfigure 2 /dev/null`
then
  { $as_echo $as_me:${as_lineno-$LINENO}: checking add-on $libc_add_on for 
preconfigure fragments 5
$as_echo_n checking add-on $libc_add_on for preconfigure fragments...  6; }
  for frag in $frags; do
name=`echo $frag | sed 's@/[^/]*$@@;s@^.*/@@'`
echo $ECHO_N $name $ECHO_C 6
. $frag
  done
  { $as_echo $as_me:${as_lineno-$LINENO}: result:  5
$as_echo  6; }
fi
  use_add_ons=$use_add_ons $libc_add_on
  add_ons_pfx=$add_ons_pfx $libc_add_on/
  test -z $libc_add_on_canonical ||
  add_ons_sfx=$add_ons_sfx /$libc_add_on_canonical
fi
  done
  # Use echo to strip excess whitespace.
  add_ons=`echo $use_add_ons`
fi

Re: libpthread fails to build as an add-on

[Manolis Ragkousis]

In the debian package I saw there are 2 patches that add this.

  +libc_add_on_canonical=libpthread
  +libc_add_on_subdirs=.

How does this change the configure process?

Re: libpthread fails to build as an add-on

[Manolis Ragkousis]

  (This is libpthread's config.log, right?)

It's the config.log generated in the build folder of glibc.
There is no config.log file generated  from libpthread.

Manolis


starting phase `configure'
source directory: 
/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-4/source (relative from 
build: ../source)
build directory: /tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-4/build
configure flags: 
(CONFIG_SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
--prefix=/gnu/store/38sz5a5r2mimzg31jg2wdvk1f173iphx-glibc-hurd-cross-i686-pc-gnu-2.18
 --enable-fast-install --target=i686-pc-gnu --without-cvs 
--enable-add-ons=libpthread --build=i686-pc-gnu --disable-profile 
--disable-multi-arch --disable-sanity-checks 
libc_cv_localedir=/gnu/store/17kg9lw4laxglif9kdcgy6vc2yz366yx-glibc-hurd-cross-i686-pc-gnu-2.18-locales/share/locale
 BASH_SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash)
checking build system type... i686-pc-gnu
checking host system type... i686-pc-gnu
checking for gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for readelf... readelf
checking for sysdeps preconfigure fragments... x86_64 
configure: running configure fragment for add-on libpthread
configure: WARNING: you should use --build, --host, --target
configure: WARNING: you should use --build, --host, --target
checking build system type... Invalid configuration `dummy': machine `dummy' 
not recognized
configure: error: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
../source/scripts/config.sub dummy failed
phase `configure' failed after 0 seconds
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU C Library configure (see version.h), which was
generated by GNU Autoconf 2.68.  Invocation command line was

  $ ../source/configure dummy readelf

## - ##
## Platform. ##
## - ##

hostname = localhost
uname -m = x86_64
uname -r = 3.13.6-1-ARCH
uname -s = Linux
uname -v = #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: 
/gnu/store/6bg25h0pzgscds0br7dzs7lf3vqskl96-gcc-cross-hurd-sans-libc-i686-pc-gnu-4.8.2/bin
PATH: 
/gnu/store/nkrr16lw55p75483z2an0c67nnqdm4l5-binutils-cross-i686-pc-gnu-2.23.2/bin
PATH: /gnu/store/m2qn6kv6n00ris4l9mwfl7wadxrbll6g-mig-cross-1.4/bin
PATH: /gnu/store/qdd0hz0sclms1rz3ss01f75r3ys8r58z-perl-5.16.1/bin
PATH: /gnu/store/bvw355kwjr21kcfckzlm22ag03xamj27-autoconf-wrapper-2.69/bin
PATH: /gnu/store/yvfsm45m5g8m2ikj8gvnq6260azwbrbk-automake-1.14.1/bin
PATH: /gnu/store/nr4xwiv2v7n97ib29dpf8gi2562y5294-libtool-2.4.2-bin/bin
PATH: /gnu/store/x26nnlh6azmnd0ibdyfwafdc6rkzx17w-bash-light-4.2/bin
PATH: /gnu/store/f4v605p9fva9kjragznh3l28nfpzmcqp-tar-1.27.1/bin
PATH: /gnu/store/7267cq3clzcbgd1k7s5rg0i0vp2yklpl-gzip-1.6/bin
PATH: /gnu/store/a1ir9y0bgaazp6n58y3qbhmfymjq3yxq-bzip2-1.0.6/bin
PATH: /gnu/store/1zs7xnaby6vl49195sid1klx3gk03mwd-xz-5.0.4/bin
PATH: /gnu/store/2ly72pfnmg28ps7jdj83516gvbn6371j-diffutils-3.3/bin
PATH: /gnu/store/1qdk13ly4c5iqqz7nay0x4fn6ls5r1b9-patch-2.7.1/bin
PATH: /gnu/store/gjl05yl9lvgjhznz5v985mys861svp34-coreutils-8.21/bin
PATH: /gnu/store/sj5ivydxwm1943y2g06vhwfwpn9hc1a1-sed-4.2.2/bin
PATH: /gnu/store/v2q2595q6n4gs32j15ga65bgy0yqg76g-grep-2.15/bin
PATH: /gnu/store/r534qbhj6jni2x30q4rgl8ry8rilarak-findutils-4.4.2/bin
PATH: /gnu/store/3j4pxqg9rskk9365m6jqi59pvcyq1d82-gawk-4.1.0/bin
PATH: /gnu/store/pwm61di9kpfks4acn0k6kp2rwa0wjl5j-make-4.0/bin
PATH: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin
PATH: /gnu/store/r7lpkp8d2df74rw24ndcivxvjzdgxn8d-ld-wrapper-0/bin
PATH: /gnu/store/xbryfykc21adgrq3z56g4c6xvv2lb645-binutils-2.23.2/bin
PATH: /gnu/store/z8qifq9172ad17a7mxg9w8jq51axwwqr-gcc-4.8.2/bin
PATH: /gnu/store/5v11czsqd9x9xqvsww9dk7h5i47laym0-glibc-2.18/bin
PATH: /gnu/store/5v11czsqd9x9xqvsww9dk7h5i47laym0-glibc-2.18/sbin


## --- ##
## Core tests. ##
## --- ##

configure:2338: checking build system type
configure:2349: error: 
/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash 
../source/scripts/config.sub dummy failed

##  ##
## Cache variables. ##
##  ##

ac_cv_build=
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=

Re: [GSoC] Porting Guix to GNU/Hurd

[Manolis Ragkousis]

Hi David

 I'm not really a Hurd developer, but I've been cross-compiling
 Hurd-from-scratch from git for a little over a year now.  Let me know
 if you get stuck or just want to see some relevant code, and we can
 share scripts and notes (at least for the earlier stages of your
 project).

Thank you for offering your help .
For now if you can point me to where I can find any relevant code you have
available for the building procedure ,especially the part for glibc and
libpthread, I will be grateful. :-)

 I'd be interested in using Guix on Hurd, so good luck with your project!

Thank you  :-)

Manolis

[GSoC] Porting Guix to GNU/Hurd

[Manolis Ragkousis]

Hello Guix , Hello Hurd

Most of you already know me from the irc ,lurking around as phant0mas and
that I am working towards porting Guix to GNU/Hurd.

In order to be able to do that I have already packaged mach headers ,hurd
headers and mig and I am currently working on packaging and cross-building
hurd's glibc with libpthread as an addon.

Here is a simple roadmap explaing what is there to be done.

1) Successfully cross-build the hurd's glibc
2) Make the appropriate changes  to cross-base.scm so the toolchain will
use the new glibc when hurd is targeted with guix build --target=i686-gnu
bootstrap-binaries
3) Successfully cross-build Guix's bootstrap binaries. This will be the
first milestone.
4) At this point we can try bootstraping guix in a native Hurd system while
starting modifying  the (gnu system) Guix modules in order to add support
for a GNU/Hurd system.
5) After adding support for a Hurd system and configuring system packages
,services , etc ,we could create a complete VM image of a GNU/Hurd system.

When we have that last one ,as it was pointed out from Thomas Schwinge in
the irc, we'll be easily able to change some detail in, say, glibc, rebuild
the whole system, and see whether it still works.

And because I am an eligible student I would like to apply as a GSoC
student working on this.

I am reading any available documentation or existing source that can help
me and I would really appreciate any suggestions ,corrections or questions
that can help me.

Manolis Ragkousis