Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/link: support internal linking for Android and iOS #31819

Open
eliasnaur opened this issue May 3, 2019 · 5 comments
Open

cmd/link: support internal linking for Android and iOS #31819

eliasnaur opened this issue May 3, 2019 · 5 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. mobile Android, iOS, and x/mobile NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@eliasnaur
Copy link
Contributor

We're about to run self-hosted Android and iOS builders (#31722). It would be nice if Go could produce internally linked binaries for those platforms, for a less hacky bootstrapping and for being able to build x/build/cmd/buildlet and stage0 everywhere. Depends on #31343 Android.
@katiehockman katiehockman added mobile Android, iOS, and x/mobile NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 3, 2019
@katiehockman
Copy link
Contributor

/cc @cherrymui @ianlancetaylor

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/207299 mentions this issue: cmd/link: bootstrap android/arm64 in internal linking mode

gopherbot pushed a commit that referenced this issue Feb 26, 2020
@eliasnaur
cmd/link: default to internal linking for android/arm64
e6d7326 
The bootstrapping process (make.bash) on all other platforms use
internal linking. This change brings android/arm64 in line, fixing the
scary warning on our self-hosted Corellium builders:

warning: unable to find runtime/cgo.a

The linkmode default is changed to internal for all Android programs,
but in practice that won't matter outside our builders: using Go with
Android apps requires buildmode=c-shared which uses linkmode external.

Fixes #31343
Updates #31819

Change-Id: I3b3ada5ed69a7989e6d8e5960bbebf5e1c22aada
Reviewed-on: https://go-review.googlesource.com/c/go/+/207299
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@mknyszek mknyszek moved this to Triage Backlog in Go Compiler / Runtime Jul 15, 2022
@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
@bcmills
Copy link
Contributor

bcmills commented Feb 28, 2023

Depends on #31343 Android.

#31343 is marked as fixed. Is there anything else preventing the use of internal linking on Android?
(https://go.dev/cl/207299 only marked it as supported on arm64)

@cherrymui
Copy link
Member

Yeah, currently we only support internal linking on Android/Arm64.

We do support internal linking PIE on Linux/AMD64. I guess it would be too hard to make android/amd64 work as well.

We don't currently support internal linking PIE on 386 or 32-bit ARM. That would need more work. Are 32-bit Android platforms still important to support?

@ajsinclair
Copy link

Are 32-bit Android platforms still important to support?

I would find it useful. We have Go binaries running on 32 bit ARM and x86 Emulators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. mobile Android, iOS, and x/mobile NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Unplanned
Development

No branches or pull requests
7 participants
@eliasnaur @ajsinclair @bcmills @gopherbot @seankhliao @cherrymui @katiehockman