Add FreeBSD support

[ldnetgate]

This change adds FreeBSD AMD64 and ARM64 targets.

Includes:

• github actions workflow with FreeBSD test unit: The FreeBSD test needs to run in its own space because it's executed as a virtualbox VM in macOS. vmactions/freebsd-vm only supports a single step block where it exits the VM process once the unit completse. All the run commands therefore need to be clumped together.

  The setup-go library doesn't support FreeBSD, so different versions of Go are manually fetched directly from the Go repo instead of using FreeBSD's pkg, which is limited to only a single version of Go.

• environ and __progname variables to enable cross-compilation which libc.so relies on. Cross-compile requires -gcflags="github.com/ebitengine/purego/internal/fakecgo=-std" to make the the symbols appear in the binary.

Sponsored by: Rubicon Communications LLC (Netgate)

[hajimehoshi]

Nice work!

Can we add tests by https://github.com/vmactions/freebsd-vm ?

[ldnetgate]

Nice work!

Can we add tests by https://github.com/vmactions/freebsd-vm ?

Not sure if this will satisfy your request (vmactions is new to me and FreeBSD is not a first class citizen of github actions); I've made a custom unit specifically for FreeBSD because of this - setup-go and different golang versions are not available for FreeBSD.

https://github.com/ldnetgate/purego/blob/freebsd-wftest/.github/workflows/test.yml

Test trigger passing: https://github.com/ldnetgate/purego/actions/runs/5951411806

I can merge it into this pull request if it's suitable. thanks.

[hajimehoshi]

I can merge it into this pull request if it's suitable.

Yes, I have some requests on the YAML file, but it is very nice to have tests for FreeBSD! Thanks,

[TotallyGamerJet]

As for the missing symbols we can do what Cgo actually does in the runtime. It has a file called runtime/cgo/freebsd.go. Unfortunately, this pragma "requires" Cgo but the compiler can be told to think that the fakecgo package is Cgo by using -gcflags="github.com/ebitengine/purego/internal/fakecgo=-std". I think this is a better approach since it means the produced binary will run without any issues and doesn't require the preload at each invocation. A comment can also be added above the pragmas so that people trying to cross-compile know what flag and why it's needed.

[ldnetgate]

Thanks for the gcflags hint, that was very useful and solves the problem we have here.

The github action passed in my fork: https://github.com/ldnetgate/purego/actions/runs/5957807111/job/16161095503

[TotallyGamerJet]

Great! Did you create the freebsd.go file in fakecgo? I don't see it.

[ldnetgate]

Great! Did you create the freebsd.go file in fakecgo? I don't see it.

Apologies, missed it during push. It's in now as go_freebsd.go and test ran: https://github.com/ldnetgate/purego/actions/runs/5958576447/job/16162985604

[TotallyGamerJet]

Thank you! We can keep the name just freebsd.go to match what it's called in runtime/cgo. Also can you add it to the README in the list of external code. The README also should have the example updated to show FreeBSD support.

[TotallyGamerJet]

Actually maybe the code itself shouldn't be updated since then we have to complicate the example to explain the special flag. I think just update the line that mentions the full example to include FreeBSD

[ldnetgate]

tweaked the two items you mentioned and tested (https://github.com/ldnetgate/purego/actions/runs/5958993688/job/16164058824)

[ldnetgate]

Not sure why github shows changes still requested; I can't see any items pending in my display.

Updated the PR description based on the changes applied.

[hajimehoshi]

@TotallyGamerJet

[hajimehoshi]

@ldnetgate I would like to understand -std of -gcflags more. I think this is undocumented, so could you give me a pointer to a source code (probably in cmd/go)? I appreciate your hard work!

EDIT:

https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/noder/noder.go;l=298-306;drc=43e69b330a71e0d101bd57f0a1ea83bc4da259f3;bpv=0;bpt=1

So -std is necessary to enable //go:cgo_export_dynamic, right?

[TotallyGamerJet]

I was the one who suggested the flag. Yes it's necessary for that pragma.

The flag is defined here.

[hajimehoshi]

Thanks!