Rust called golang func by ffi failed on windows

[oligamiq]

Hi, I love rust and golang both!

Rust call golang by ffi.
windows11:
stable & beta & nightly:

    error: linking with `link.exe` failed: exit code: 1120
    libstd-d9ee307034db292c.rlib(std-d9ee307034db292c.std.e9da0a539f4e1ec4-cgu.0.rcgu.o) : warning LNK4078: multiple '.drectve' sections found with different attributes (00100A00)
              libffi_go_print.lib(000005.o) : error LNK2019: unresolved external symbol fprintf referenced in function _cgo_beginthread
              C:\Users\oligami\ffi-rust-go\target\debug\deps\ffi_rust_go.exe : fatal error LNK1120: 1 unresolved externals

wsl(ubuntu22):
stable & beta & nightly:
conplete

:print on rust
:print on golang
program end

alpine(docker):
stable & beta & nightly: segmentation fault on golang func

:print on rust
Segmentation fault

code on https://github.com/oligami-0424/ffi-rust-go
I tried this code:

package main

import (
	"C"
)
//export ffi_go_print
func ffi_go_print() {
	println(":print on golang")
}

extern "C" {
    fn ffi_go_print();
}

fn main() {
    println!(":print on rust");
    unsafe { ffi_go_print() };

    println!("program end");
}

fn main() {
    cgo_oligami::Build::new()
        .build_mode(cgo_oligami::BuildMode::CArchive)
        .change_dir("./golib")
        .package("main.go")
        .build("ffi_go_print");

    println!("cargo:rerun-if-changed=golib/main.go");
}

I expected to see this happen: success on all

Instead, this happened: success on only ubuntu

rustc --version --verbose:
windows11

rustc 1.72.1 (d5c2e9c34 2023-09-13)
binary: rustc
commit-hash: d5c2e9c342b358556da91d61ed4133f6f50fc0c3
commit-date: 2023-09-13
host: x86_64-pc-windows-msvc
release: 1.72.1
LLVM version: 16.0.5

ubuntu(wsl)

rustc 1.72.1 (d5c2e9c34 2023-09-13)
binary: rustc
commit-hash: d5c2e9c342b358556da91d61ed4133f6f50fc0c3
commit-date: 2023-09-13
host: x86_64-unknown-linux-gnu
release: 1.72.1
LLVM version: 16.0.5

alpine

rustc 1.72.0 (5680fa18f 2023-08-23)
binary: rustc
commit-hash: 5680fa18feaa87f3ff04063800aec256c3d4b4be
commit-date: 2023-08-23
host: x86_64-unknown-linux-musl
release: 1.72.0
LLVM version: 16.0.5

[workingjubilee]

libffi_go_print.lib(000005.o) : error LNK2019: unresolved external symbol fprintf referenced in function _cgo_beginthread

I don't see how we could begin to realistically solve this and make it stay solved? This is a missing function referenced by the Go code, and we don't know what steps CGo normally takes to make this compile and link correctly. It likely only links correctly by accident on Ubuntu.

[oligamiq]

This program succussed on mac-pc

[bjorn3]

On macOS all dynamic libraries which Go depend on are likely already depended on by Rust or added by default by the linker. On Windows this is likely not the case. You may want to open an issue for cgo_oligami as that crate is responsible for making sure everything necessary to successfully link Go is in place.

[bjorn3]

As for the alpine issue, you may be hitting golang/go#13492.

[oligamiq]

@bjorn3
@workingjubilee

I search golang issue and found golang/go#17014.

Golang is not support llvm on windows so Rust cannot link Golang staticlib on windows!!

This is bad news, but I know reason.

Thank you bjorn3, workingjubilee!!

[workingjubilee]

On macOS all dynamic libraries which Go depend on are likely already depended on by Rust or added by default by the linker. On Windows this is likely not the case. You may want to open an issue for cgo_oligami as that crate is responsible for making sure everything necessary to successfully link Go is in place.

Coder went to the compiler one day,
said they don't know what to do,
said they don't know how to make Go on Windows link to Rust,
said the world seems threatening and uncertain, and they're completely depressed!
And the compiler said, "Treatment is simple.
The great maintainer Oligami is in town tonight.
Go and see them. They should fix your issue."
And the coder bursts into tears,
"Compiler,
I am the great maintainer Oligami!"

[oligamiq]

I added dependencies on mac because stackoverflow sample.
And generated file name is small failed etc.,
Forking source library cannot run without linux so, he may test on only linux.