From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3e48dd242575c851e2d9bfe54c417e2d@proxima.alt.za>
To: lucio@proxima.alt.za, 9fans@9fans.net
From: Lucio De Re <lucio@proxima.alt.za>
Date: Mon, 11 Apr 2011 16:21:21 +0200
In-Reply-To: <3a521a083f982c99e490cdc3b814f0e5@proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] Plan 9 port of the Go toolchain
Topicbox-Message-UUID: cfa89c48-ead6-11e9-9d60-3106f5b1d025

>> PS: I still can't link an executable with the version of 8l from the
>> Go toolchain that I built under Plan 9, but I'm hoping to get there
>> soon.
>=20
> It's of some consolation to me that I see exactly the same results
> under Ubuntu, so that particular problem isn't in the 8l executable
> created for Plan 9.  I may have something exciting to report on this
> issue within the day.
>=20
Having rebuilt a copy of runtime.a as well as of "hell-o.8", I now
have an executable created from "hell-o.go" that runs sucessfully
under Plan 9 after having been linked with an "8l" from the Go
toolchain built entirely under Plan 9.  If I were any good with
picture I'd try to make the above easier to visualise.

It seems to me that, contrary to Pavel's careful statement, '8g"
itself is not agnostic regarding the "GOOS=3Dplan9" environment
variable: I'll stick out my neck and claim without sufficient
investigation that (a) the object code is flagged with the
architecture name and (b) that the module functions init() and main()
are labelled with a period (main.main) versus with the Go-special
mid-line dot (middle-dot or UTF-00b7 as in "main=C2=B7main") in Linux and
Plan 9 respectively.

I would like to upload the modified Go toolchain source code I used to
produce "8l" under Plan 9 to "sources", but I'll wait to find that
there is some interest as well as suggestions on the best approach to
submit these sources to review and testing by others.  I have
everything at hand to reproduce these sources, but some help will be
needed to tie up any lose ends from outside the Go toolchain sources.

And, once again, many thanks to Pavel (and the Go Authors, of course)
for making this possible and assisting with it.  My next task will be
to make similar changes to "8a", "8c" and "8g" to complete the series
of 386 tools.  But I also want to submit the changes in "src/cmd/8l"
and "src/cmd/ld" to the Go Authors for inclusion in future releases,
but that isn't going to be a trouble-free request, the changes have
been rather pervasive.

++L