GSoC: Porting Guix to Hurd week 2 report

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: Porting Guix to Hurd week 2 report

[Andreas Enge]

On Fri, May 15, 2015 at 10:17:14PM +0300, Manolis Ragkousis wrote:
> 5) Tomorrow if not today I will have ready the bootstrap-tarballs.

That sounds great, keep us updated when it happens!

Andreas

Re: GSoC: Porting Guix to Hurd week 2 report

[Ludovic Courtès]

Hello,

Thanks for the update, it all seems to be on track!

Hopefully the availability of the glibc-hurd tarball allow the code to
be simplified, and the Hurd-specific parts of the glibc recipes to be
reduced.

> 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?

In an ideal world, the only differences between the two libcs would be
the source (and version) and the inputs.  How far are we from that now?

If we can achieve that, we’ll be able to keep a single glibc recipe.  If
there are other differences, we’ll see.

> 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.

No problem!

Cheers,
Ludo’.