all: add GOOS=android
As android and linux have significant overlap, and
because build tags are a poor way to represent an
OS target, this CL introduces an exception into
go/build: linux is treated as a synonym for android
when matching files.
http://golang.org/s/go14android
https://groups.google.com/forum/#!topic/golang-dev/P1ATVp1mun0
Hello golang-codereviews@googlegroups.com (cc: golang-codereviews@googlegroups.com, rsc@golang.org), I'd like you to review this change to https://code.google.com/p/go
I'm not so hot on the idea of android being an alias for linux, we didn't do
that we we added nacl support.
I'd like to hear from others, but I don't think there is a case to add more
magic to the build tool.
On 2014/06/23 07:40:03, dfc wrote:
> I'm not so hot on the idea of android being an alias for linux, we didn't do
> that we we added nacl support.
>
> I'd like to hear from others, but I don't think there is a case to add more
> magic to the build tool.
I am not keen on an exception either, but the alternatives seem worse. An
android build tag plays poorly with cross compiling builds. I also tried
renaming all the linux files to linuxesque and using //+build android linux, but
it was incredibly ugly.
On Mon, Jun 23, 2014 at 2:18 AM, <crawshaw@golang.org> wrote:
> Description:
> all: add GOOS=android
>
> As android and linux have significant overlap, and
> because build tags are a poor way to represent an
> OS target, this CL introduces an exception into
> go/build: linux is treated as a synonym for android
> when matching files.
>
I think exceptions like this is even worse than duplicated code.
What's wrong with just add an android build tag?
On Mon, Jun 23, 2014 at 2:23 PM, minux <minux@golang.org> wrote:
>
> On Mon, Jun 23, 2014 at 2:18 AM, <crawshaw@golang.org> wrote:
>>
>> Description:
>> all: add GOOS=android
>>
>> As android and linux have significant overlap, and
>> because build tags are a poor way to represent an
>> OS target, this CL introduces an exception into
>> go/build: linux is treated as a synonym for android
>> when matching files.
>
> I think exceptions like this is even worse than duplicated code.
>
> What's wrong with just add an android build tag?
Built tags don't work very well. E.g. binaries go into
go/pkg/GOOS_GOARCH, so cross compiling android/amd64 from linux/amd64
with build tags is messy. And android as used will always be cross
compiled (though admittedly, amd64 isn't there yet, but there are more
android x86 devices than I realized).
Another example: tags are no plumbed through to cmd/ld.
On Mon, Jun 23, 2014 at 2:42 PM, David Crawshaw <crawshaw@golang.org> wrote:
> On Mon, Jun 23, 2014 at 2:23 PM, minux <minux@golang.org> wrote:
> > What's wrong with just add an android build tag?
>
Built tags don't work very well. E.g. binaries go into
> go/pkg/GOOS_GOARCH, so cross compiling android/amd64 from linux/amd64
> with build tags is messy.
this is a general problem of using build tags, we can solve that with
InstallSuffix
(like what race does).
> And android as used will always be cross
> compiled (though admittedly, amd64 isn't there yet, but there are more
> android x86 devices than I realized).
>
> Another example: tags are no plumbed through to cmd/ld.
>
the linker should be generic, why should the linker for android/arm be
different
from linux/arm?
generating a shared library is also a generic feature that is not limited
to android.
On Mon, Jun 23, 2014 at 3:52 PM, minux <minux@golang.org> wrote:
>
> On Mon, Jun 23, 2014 at 2:42 PM, David Crawshaw <crawshaw@golang.org> wrote:
>>
>> On Mon, Jun 23, 2014 at 2:23 PM, minux <minux@golang.org> wrote:
>> > What's wrong with just add an android build tag?
>>
>> Built tags don't work very well. E.g. binaries go into
>> go/pkg/GOOS_GOARCH, so cross compiling android/amd64 from linux/amd64
>> with build tags is messy.
>
> this is a general problem of using build tags, we can solve that with
> InstallSuffix
> (like what race does).
Sure, we can shoehorn this into build tags. But why? Android is an
operating system.
>>
>> And android as used will always be cross
>> compiled (though admittedly, amd64 isn't there yet, but there are more
>> android x86 devices than I realized).
>>
>>
>> Another example: tags are no plumbed through to cmd/ld.
>
> the linker should be generic, why should the linker for android/arm be
> different
> from linux/arm?
> generating a shared library is also a generic feature that is not limited to
> android.
The shared library is generated by the external linker, almost all of
that works. What's missing for cgo support is TLS emulation, which
Elias implemented in cl 69170045. It needs some android-specific
linker changes:
https://codereview.appspot.com/69170045/diff/40001/src/cmd/ld/symtab.c
On Mon, Jun 23, 2014 at 4:15 PM, David Crawshaw <crawshaw@golang.org> wrote:
> On Mon, Jun 23, 2014 at 3:52 PM, minux <minux@golang.org> wrote:
> > this is a general problem of using build tags, we can solve that with
> > InstallSuffix
> > (like what race does).
>
> Sure, we can shoehorn this into build tags. But why? Android is an
> operating system.
But for Go, GOOS essentially specify the kernel/user space interface. The
same
kernel should use the same GOOS. What the marketing calls is irrelevant
here.
For example, if Go adds support for Debian/kFreeBSD in the future, it
should use
GOOS=freebsd, instead of inventing a new GOOS. And the kfreebsd case is very
similar to the android case (the entire user space is replaced, only the
kernel
remains the same.)
Also, should we use GOOS=ios for the iOS port? Apple certainly calls iOS an
operating system, and I don't think they've ever used darwin to refer to
iOS.
>> And android as used will always be cross
> >> compiled (though admittedly, amd64 isn't there yet, but there are more
> >> android x86 devices than I realized).
> >>
> >>
> >> Another example: tags are no plumbed through to cmd/ld.
> > the linker should be generic, why should the linker for android/arm be
> > different
> > from linux/arm?
> > generating a shared library is also a generic feature that is not
> limited to
> > android.
>
> The shared library is generated by the external linker, almost all of
> that works. What's missing for cgo support is TLS emulation, which
> Elias implemented in cl 69170045. It needs some android-specific
> linker changes:
> https://codereview.appspot.com/69170045/diff/40001/src/cmd/ld/symtab.c
>
That is not the only solution. See, for example, what darwin does with the
hard-
coded TLS offset.
The worse case is we have to use the same code on all arm platforms, but
that's not a big deal.
[Note that after eliminating m, we only need a single TLS slot, so it will
make
the TLS reservation much easier (we don't need two adjacent TLS slots, only
one suffice.)]
On Mon, Jun 23, 2014 at 4:36 PM, minux <minux@golang.org> wrote:
>
> On Mon, Jun 23, 2014 at 4:15 PM, David Crawshaw <crawshaw@golang.org> wrote:
>>
>> On Mon, Jun 23, 2014 at 3:52 PM, minux <minux@golang.org> wrote:
>> > this is a general problem of using build tags, we can solve that with
>> > InstallSuffix
>> > (like what race does).
>>
>> Sure, we can shoehorn this into build tags. But why? Android is an
>> operating system.
>
> But for Go, GOOS essentially specify the kernel/user space interface. The
> same
> kernel should use the same GOOS. What the marketing calls is irrelevant
> here.
The android user space has the potential to vary significantly from
linux. The only thing android guarantees is what's exported in bionic.
So far it doesn't seem to diverge far from linux, which is certainly
nice, but it wouldn't surprise me to find a bunch of corner cases that
require hooks for JNI code provided by go.mobile.
> For example, if Go adds support for Debian/kFreeBSD in the future, it should
> use
> GOOS=freebsd, instead of inventing a new GOOS. And the kfreebsd case is very
> similar to the android case (the entire user space is replaced, only the
> kernel
> remains the same.)
>
> Also, should we use GOOS=ios for the iOS port? Apple certainly calls iOS an
> operating system, and I don't think they've ever used darwin to refer to
> iOS.
I don't see why not. Though GOOS=ios would refer to whatever
modifications are required to get Go into an iOS app via xcode, not
running a binary on a jailbroken device.
Though I don't particularly care what color this is. All I want is a
way to integrate Android code. My instinct is GOOS, but I'm happy to
leave the decision to the reviewer.
>
>> >> And android as used will always be cross
>> >> compiled (though admittedly, amd64 isn't there yet, but there are more
>> >> android x86 devices than I realized).
>> >>
>> >>
>> >> Another example: tags are no plumbed through to cmd/ld.
>> > the linker should be generic, why should the linker for android/arm be
>> > different
>> > from linux/arm?
>> > generating a shared library is also a generic feature that is not
>> > limited to
>> > android.
>>
>> The shared library is generated by the external linker, almost all of
>> that works. What's missing for cgo support is TLS emulation, which
>> Elias implemented in cl 69170045. It needs some android-specific
>> linker changes:
>> https://codereview.appspot.com/69170045/diff/40001/src/cmd/ld/symtab.c
>
>
> That is not the only solution. See, for example, what darwin does with the
> hard-
> coded TLS offset.
> The worse case is we have to use the same code on all arm platforms, but
> that's not a big deal.
> [Note that after eliminating m, we only need a single TLS slot, so it will
> make
> the TLS reservation much easier (we don't need two adjacent TLS slots, only
> one suffice.)]
Good news!
On Mon, Jun 23, 2014 at 10:49 PM, David Crawshaw <crawshaw@golang.org> wrote:
> The android user space has the potential to vary significantly from
> linux.
GOOS, at least for now, is primarily setting the kernel interface,
whether the user-space will change is inconsequential. For android we
might care about the specifics of particular shared libraries we need
to interact with, that's why there's work to be done, but it's just
the same kernel interface.
GOOS also changes TLS access procedure; this is also not
android-specific, making it work on android will open the door to cgo
programs working of other embedded Linux systems that don't use glibc.
That being said, having support for android does require a way for the
user to set it. GOOS is a very simple way to set it. go build -tags
android is not enough by itself, and go build -android seems just to
introduce a very special case just like special-casing GOOS. As I
said, I don't have any good solution.
--
Aram Hăvărneanu
On Monday, June 23, 2014 11:36:24 PM UTC+2, Aram Hăvărneanu wrote:
> On Mon, Jun 23, 2014 at 10:49 PM, David Crawshaw wrote:
>
> > The android user space has the potential to vary significantly from
>
> > linux.
>
>
>
> GOOS, at least for now, is primarily setting the kernel interface,
>
> whether the user-space will change is inconsequential. For android we
>
> might care about the specifics of particular shared libraries we need
>
> to interact with, that's why there's work to be done, but it's just
>
> the same kernel interface.
>
>
>
> GOOS also changes TLS access procedure; this is also not
>
> android-specific, making it work on android will open the door to cgo
>
> programs working of other embedded Linux systems that don't use glibc.
>
>
>
> That being said, having support for android does require a way for the
>
> user to set it. GOOS is a very simple way to set it. go build -tags
>
> android is not enough by itself, and go build -android seems just to
>
> introduce a very special case just like special-casing GOOS. As I
>
> said, I don't have any good solution.
>
>
>
> --
>
> Aram Hăvărneanu
I agree that neither GOOS nor build tag are ideal for the Android case, and I
also alternated between those two in my own Android CLs. However, building on
what Minux said about darwin TLS and Aram's point about non-glibc systems,
perhaps it is possible to let the go linker optimistically assume TLS support in
the native dynamic linker?
In other words, let the Go linker on linux use the glibc TLS relocations to set
up TLS. Then, at runtime, detect whether TLS works, and if not, fall back to
pthread-based TLS emulation the way darwin does. That way, Android will be a
linux that just happens to have a less featured dynamic linker.
- elias
On Tue, Jun 24, 2014 at 12:53 AM, <elias.naur@gmail.com> wrote:
>
> I agree that neither GOOS nor build tag are ideal for the Android case, and I
also alternated between those two in my own Android CLs. However, building on
what Minux said about darwin TLS and Aram's point about non-glibc systems,
perhaps it is possible to let the go linker optimistically assume TLS support in
the native dynamic linker?
>
> In other words, let the Go linker on linux use the glibc TLS relocations to
set up TLS. Then, at runtime, detect whether TLS works, and if not, fall back to
pthread-based TLS emulation the way darwin does. That way, Android will be a
linux that just happens to have a less featured dynamic linker.
I don't see how to safely test whether TLS works without clobbering
random memory.
Android is a Linux kernel, yes, but the libc is entirely different,
and that is not irrelevant. Given that we only have one axis on which
to describe the operating system, I think that GOOS=android makes
sense. I think it's either that or introduce a new environment
variable.
To configure GCC for Android you use --target=arm-linux-androideabi,
not arm-linux.
Ian
There are no perfect solutions here. I believe that GOOS=android is the least imperfect, and ...
9 years, 12 months ago
(2014-07-01 18:40:27 UTC)
#18
There are no perfect solutions here. I believe that GOOS=android is the least
imperfect, and it will let us make progress. If we gather evidence that this was
a mistake we can revisit the decision in light of that evidence.
With the change below I think most of this CL goes away. Please revise.
https://codereview.appspot.com/105270043/diff/140001/src/pkg/go/build/build.go
File src/pkg/go/build/build.go (right):
https://codereview.appspot.com/105270043/diff/140001/src/pkg/go/build/build.g...
src/pkg/go/build/build.go:1127: if name == ctxt.GOOS || name == ctxt.GOARCH ||
name == ctxt.Compiler {
|| ctxt.GOOS == "android" && name == "linux"
this will remove 90% of the CL
9 years, 12 months ago
(2014-07-01 21:11:42 UTC)
#22
https://codereview.appspot.com/105270043/diff/160001/src/cmd/dist/build.c
File src/cmd/dist/build.c (right):
https://codereview.appspot.com/105270043/diff/160001/src/cmd/dist/build.c#new...
src/cmd/dist/build.c:1153: return streq(f, goos) || streq(f, goarch) || streq(f,
"cmd_go_bootstrap") || streq(f, "go1.1") || (streq(goos, "android") && streq(f,
"linux"));
On 2014/07/01 20:50:52, rsc wrote:
> glad we don't have go1.2 or go1.3 code in the repo
do you want them added here, or go1.1 removed from here? (in a followup cl)
for the latter, the go1.1 tag test would have to move into a test that cmd/dist
doesn't build.
https://codereview.appspot.com/105270043/diff/160001/src/pkg/go/build/doc.go
File src/pkg/go/build/doc.go (right):
https://codereview.appspot.com/105270043/diff/160001/src/pkg/go/build/doc.go#...
src/pkg/go/build/doc.go:115: // have an implicit build constraint requiring
those terms. An exception is
On 2014/07/01 21:04:35, minux wrote:
> On 2014/07/01 20:50:52, rsc wrote:
> > // Using GOOS=android matches the linux build tag and *_linux.* files in
> > addition
> > // to android ones.
> *_linux.* doesn't cover all the cases,
> i think "file patterns as if GOOS=linux" is better.
How about:
// Using GOOS=android matches build tags and files as if GOOS=linux
// in addition to android ones.
*** Submitted as https://code.google.com/p/go/source/detail?r=4db0802fd3fd *** all: add GOOS=android As android and linux have significant overlap, ...
9 years, 12 months ago
(2014-07-01 21:22:06 UTC)
#25
Issue 105270043: code review 105270043: all: add GOOS=android
(Closed)
Created 10 years ago by crawshaw
Modified 9 years, 12 months ago
Reviewers: gobot
Base URL:
Comments: 20
