x/mobile: gccgo to resolve the issue of multiple SDK conflicts ?

[Grégoire Truhé]

Hello golang-nuts,

I hope this is the right place to ask this question. 

Note that I have already asked this in gofrontend-dev conversation but it seems less lively than here.

## Context

I'm developing an Android application that integrates multiple Go SDKs (business logic libraries). Currently, I'm using gomobile bind to produce .aar files for each SDK. However, I'm hitting a well-known issue: each .aar embeds its own Go runtime (libgojni.so), and loading multiple of them in the same process leads to runtime conflicts and crashes (SIGSEGV in runtime.(*mheap).allocNeedsZero, caused by two GC heaps competing).

## Idea

I came across gccgo/libgo and its dynamic linking philosophy: instead of embedding the runtime in each binary, binaries depend on a shared libgo.so at runtime. This seems like exactly the right architecture to solve my problem:

  libgo.so          ← shared Go runtime, loaded once
  libsdk1.so        ← depends on libgo.so
  libsdk2.so        ← depends on libgo.so

On Linux/glibc this works well. My question is about Android.

## Question

Android uses bionic as its libc instead of glibc. I noticed in the libgo README (under gcc/libgo) the following:

  "The libgo library has only been tested on GNU/Linux using glibc."

But also, encouragingly:

  "It should not be difficult to port to other operating systems."

I would like to ask:

1. Has anyone attempted to build libgo targeting aarch64-linux-android (using the Android NDK sysroot with bionic)?

2. What would be the main obstacles?

3. Is this something the community would consider a reasonable effort, or are there known fundamental blockers?

Any guidance, pointers to prior work, or honest assessment of feasibility would be greatly appreciated. I'm willing to contribute and test if someone can point me in the right direction.

Thank you for your time.

Greg T.

[Jason E. Aten]

I think regular gc can do this. Research the -linkshared flag and -buildmode=shared. Something like

go install -x -buildmode=shared -linkshared std

go build -buildmode=shared -linkshared -o mypackage.so ./path/to/package

go build -linkshared -o myapp main.go

[Ian Lance Taylor]

On Wed, Apr 8, 2026 at 9:58 AM Grégoire Truhé <hgregoi...@gmail.com> wrote:
>
> 3. Is this something the community would consider a reasonable effort, or are there known fundamental blockers?

Unfortunately gccgo has not kept pace with language changes since the
introduction of generics, so this is not a viable approach.

Ian

[Greg T]

Thanks for the suggestion. I was able to compile std as a shared library (libstd.so) successfully, but compiling a package with -buildmode=shared crashes the linker with makeslice: cap out of range in loader.go. This confirms the issue mentioned in golang/go#47788 — -buildmode=shared for user packages is broken with modules.

[Greg T]

Thank you for the honest answer regarding gccgo's current state.

I understand that gccgo has fallen behind gc since generics were introduced, which makes it a non-starter for production use today.

However, I'd like to ask a purely architectural question, setting aside the generics gap and the current maintenance state of gccgo:

If gccgo were fully up to date with the Go spec, would the approach of building libgo.so for Android/bionic be architecturally sound as a solution to the multiple Go runtime conflict problem?

[Jason E. Aten]

On Thursday, April 9, 2026 at 4:45:19 AM UTC-3 Greg T wrote:

Thanks for the suggestion. I was able to compile std as a shared library (libstd.so) successfully, but compiling a package with -buildmode=shared crashes the linker with makeslice: cap out of range in loader.go. This confirms the issue mentioned in golang/go#47788 — -buildmode=shared for user packages is broken with modules.

Since you are already off the beaten path, I will just point out that it is not that hard to build in (pre 2015) GOPATH mode if you want to try and make -buildmode=shared work for your Android use case. Before you switch to GO111MODULE=off, do a "go mod vendor" in module mode. This will populate vendor/ which the exact versions of your dependencies.  Then manually move the contents of the vendor/ folder into your GOPATH.  Sure its a hassle, but you're trying to make Go work in uncommon places, so some hassle can be expected. You will have to manually insert an v2/ or v3/ directories, of course.

[Ian Lance Taylor]

On Thu, Apr 9, 2026 at 12:51 AM Greg T <hgregoi...@gmail.com> wrote:
>
> Thank you for the honest answer regarding gccgo's current state.
>
> I understand that gccgo has fallen behind gc since generics were introduced, which makes it a non-starter for production use today.
>
> However, I'd like to ask a purely architectural question, setting aside the generics gap and the current maintenance state of gccgo:
>
> If gccgo were fully up to date with the Go spec, would the approach of building libgo.so for Android/bionic be architecturally sound as a solution to the multiple Go runtime conflict problem?

Yes, I believe it would.

Ian

> Le jeudi 9 avril 2026 à 00:28:45 UTC+2, Ian Lance Taylor a écrit :
>>
>> On Wed, Apr 8, 2026 at 9:58 AM Grégoire Truhé <hgregoi...@gmail.com> wrote:
>> >
>> > 3. Is this something the community would consider a reasonable effort, or are there known fundamental blockers?
>>
>> Unfortunately gccgo has not kept pace with language changes since the
>> introduction of generics, so this is not a viable approach.
>>
>> Ian
>

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/1ff78040-986b-4dd8-8f0a-501bf51a4b73n%40googlegroups.com.