[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurd port for GCC Go
Re: Hurd port for GCC Go
Thu, 13 Jun 2013 10:39:58 +0200
Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)
On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell <firstname.lastname@example.org>
> On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote:
> > On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell
> > <email@example.com> wrote:
> > > Attached are patches to enable gccgo to build properly on Debian
> > > GNU/Hurd on gcc-4.7 (4.7.3-4).
> > Thanks! I've begun integrating them into my GCC tree (based on upstream
> > GCC trunk, so some changes to be done to your patches), and get it in a
> > state for Fotis to base his GSoC work on.
> Where to find your GCC tree?
Only locally at the moment; will find a place to publish it. As the .git
directory weighs in the order of 1 GiB, I don't just want to push that
onto darnassus (for example); even if we told people to first clone the
upstream Git repository and only then add darnassus as an additional
remote, I bet some would forget doing that. Hmm, it seems that I might
be able to host Git branches upstream, so I'll explore that:
I got as far as having GCC Go compiling with GCC trunk sources; more to
> Also I had problems to tracing this commit:
> I did not find anything related to context_functions at
Follow »[...]« in the Branches section to see all branches. Anyway, it's
a TopGit branch,
<http://www.gnu.org/software/hurd/source_repositories/glibc.html>, so for
getting a patch out of that, you'll need to diff the top of that branch
against its base branch, using »tg patch t/context_functions« if you have
TopGit installed, or something like »git diff
top-bases/t/context_functions t/context_functions« manually.
> Furthermore, for testing purposes, is it straight-forward to add the new
> functions getcontext/setcontext/makecontext*/movecontext to the debian
> sources, e.g. 2.13-39+hurd.3 or 2.17-6 (when that is released?).
It is, and Samuel is already building 2.17-3+hurd.4 packages, so you
might just wait for these to appear on debian-ports. (The patch already
was in his last night's 2.17-3+hurd.3 build, but that one turned out to
be missing another important patch (DNS resolving), as he told in his
> should these be placed in the tree: hurd/, sysdeps/mach/hurd/,
As indidacted in the patch.
> And how to avoid the stubs at stdlib/ being compiled in?
As soon as there are "more specific" implementation files (that is, these
added by me), the stub ones will no longer be considered by glibc's build
Description: PGP signature