Additional information - can confirm that I've been able to reproduce the problem on:

1. A newly created VPS with:

   • Ubuntu 22.04 x64
   • go version go1.18.1 linux/amd64

2. A newly created VPS with:

   • Windows 2022 Standard
   • go version go1.18.1 windows/amd64
   • gcc (tdm64-1) 10.3.0

root cause is the files order, last file time_profiles.go need the type override main.go define the type(cgo tool use global var typedef), so i guess can't ref type cross file in cgo(satisfy the current go file)

Oh, right .. if I build with the source files specified individually and main.go as the last file it compiles ok.

go build -trimpath -buildmode=c-shared -o ./lib/libuhppoted.so ./... seemingly compiles the files in (reverse ?) alphabetical order (or presumably directory order) which is why cards.go compiles just fine but time_profiles.go does not. Not having come across this problem before I had always assumed the compiler/linker was automatically resolving ordering issues.

Thanks - I'll dig a bit into the options to see if there's an alternative to manually specifying the files, but this issue can be closed.

Ref. go/issues/38186: cmd/compile: builds not reproducible if input file order is different

To ensure reproducible initialization behavior, build systems are encouraged to present multiple files belonging to the same package in lexical file name order to a compiler.
(https://tip.golang.org/ref/spec#Package_initialization)

In short, the order in which files are presented to the compiler matters. It is the responsibility of the build tool to provide the files in some reproducible order.

I am going to close this since the spec is pretty clear. I believe the go tool sorts the filenames for reproducible behavior

Reopening because I think there is still a bug here. Renaming the source files in a package should not have a significant effect on the result. It certainly shouldn't change between a successful build and a failing build.

When phrased like that it does sound like there may be more to it - it was certainly unexpected behaviour and the workaround is inconvenient even in such a small project.

Some additional info - building with the -work option the generated _cgo_gotypes.go file shows the difference in the generated code:

succeeded:

type _Ctype_struct_Card struct {
	card_number _Ctype_uint32_t
}

type _Ctype_struct_TimeProfile struct {
	profile_id _Ctype_uint32_t
}

failed:

type _Ctype_struct_Card struct {
	card_number _Ctype_uint32_t
}

//go:notinheap
type _Ctype_struct_TimeProfile struct{}

Change https://go.dev/cl/404497 mentions this issue: cmd/cgo: dont override declared struct type

Ok, I can confirm that 404497: cmd/cgo: dont override declared struct type seems to fix the immediate problem:

go version
go version devel go1.19-a4af356075 Fri May 6 20:17:52 2022 +0000 linux/amd64

go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so ./...
go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so dll/cards.go         dll/main.go          dll/time_profiles.go
go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so dll/cards.go         dll/time_profiles.go dll/main.go
go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so dll/main.go          dll/cards.go         dll/time_profiles.go 
go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so dll/main.go          dll/time_profiles.go dll/cards.go
go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so dll/time_profiles.go dll/cards.go         dll/main.go
go build -trimpath -buildmode=c-shared  -o ./lib/libuhppoted.so dll/time_profiles.go dll/main.go          dll/cards.go

I'm still a bit puzzled about why cgo was generating incorrect an incorrect struct definition in the first place i.e. why did it create:

//go:notinheap
type _Ctype_struct_TimeProfile struct{}

when the only mention in time_profiles.go is as a func parameter:

func getTimeProfile(profile *C.struct_TimeProfile, deviceID uint32, profileID uint32) error {
...
}

cgo dont know player how to use the struct declaration, in pure c, empty declaration is use for previously-declared struct, most of time use for handle.