* GSoC: Porting Guix to Hurd week 2 report
@ 2015-05-15 19:17 Manolis Ragkousis
2015-05-16 7:06 ` Andreas Enge
2015-05-16 19:11 ` Ludovic Courtès
0 siblings, 2 replies; 3+ messages in thread
From: Manolis Ragkousis @ 2015-05-15 19:17 UTC (permalink / raw)
To: Guix-devel, bug-hurd; +Cc: Samuel Thibault
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GSoC: Porting Guix to Hurd week 2 report
2015-05-15 19:17 GSoC: Porting Guix to Hurd week 2 report Manolis Ragkousis
@ 2015-05-16 7:06 ` Andreas Enge
2015-05-16 19:11 ` Ludovic Courtès
1 sibling, 0 replies; 3+ messages in thread
From: Andreas Enge @ 2015-05-16 7:06 UTC (permalink / raw)
To: Manolis Ragkousis; +Cc: Guix-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GSoC: Porting Guix to Hurd week 2 report
2015-05-15 19:17 GSoC: Porting Guix to Hurd week 2 report Manolis Ragkousis
2015-05-16 7:06 ` Andreas Enge
@ 2015-05-16 19:11 ` Ludovic Courtès
1 sibling, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2015-05-16 19:11 UTC (permalink / raw)
To: Manolis Ragkousis; +Cc: Guix-devel, bug-hurd, Samuel Thibault
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’.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-05-16 19:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-15 19:17 GSoC: Porting Guix to Hurd week 2 report Manolis Ragkousis
2015-05-16 7:06 ` Andreas Enge
2015-05-16 19:11 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.