Shared object / DLL support

[seadra]

gc compiler has -buildmode=c-shared.
With LLVM, this should be possible, no?

[aykevl]

Yes, this is certainly possible. It's just that no one has asked for it yet.
It will need the extra -buildmode flag and some extra hooks, like an extra -static flag to the linker and an extra hook to let the compiler emit PIC code instead of static code:

tinygo/compiler/compiler.go

Line 105 in 5569cd1

c.machine = target.CreateTargetMachine(config.Triple, config.CPU, "", llvm.CodeGenLevelDefault, llvm.RelocStatic, llvm.CodeModelDefault)

[JasonWeise]

This would be a great addition.
I am calling a Go library from Rust and would love to see it compiled with TinyGo instead.

Looking forward to this implementation :)

[sowelipililimute]

Yes, this is certainly possible. It's just that no one has asked for it yet.
It will need the extra -buildmode flag and some extra hooks, like an extra -static flag to the linker and an extra hook to let the compiler emit PIC code instead of static code:

tinygo/compiler/compiler.go

Line 105 in 5569cd1

c.machine = target.CreateTargetMachine(config.Triple, config.CPU, "", llvm.CodeGenLevelDefault, llvm.RelocStatic, llvm.CodeModelDefault)

Is adding this really all that needs to be done? Seems like there would be more to do...

[aykevl]

It's likely some more plumbing needs to be done but that's the essence of it I think.

[ansiwen]

I'm using go with c-shared for building a small plugin .so, that basically only calls a rest API. So it mainly uses the http client and json parser. Because of the runtime, it's quite big. I think it would be very useful to compile this with tinygo instead.

[riaan-dau]

We have an existing C-codebase running bare-metal on 32-bit ARM and would like to make use of the -buildmode=c-archive flag to build a static Go library callable from C. Would this be possible if this feature is implemented?

[Jimmy2099]

It's almost 2023, how is going to support generate .dll or .lib

[wayneforrest]

I am also interested in this feature.

I am using a go .dll / .lib, called from C++; and the DLL is 13MB, while the C++ code is only 1.5MB.

[31]

The Go c-shared support doesn't allow dlclose (or FreeLibrary on Windows), which makes it not ideal for plugins that need to be reloaded. I don't see any reason it'd be easier to support this with TinyGo than Go, but maybe this scenario has more value here? Go issue about this:

• runtime: support dlclose with -buildmode=c-shared golang/go#11100

[turbolent]

Is there a simple way to do this manually at the moment? For example, compile to e.g. .o or .ll, and link the runtime?

[aykevl]

Not easily, you'd have to manually initialize the runtime, run package initializers, pass -scheduler=none because there is no scheduler, and make sure the functions aren't being called from more than one place.

Maybe I'll add support for this at some point since there seems to be demand for this feature.