I also (prematurely) created PR #64591 for this.

go tool cgo is not really intended to be called directly by Go users: generally one is expected to use go build instead.

go tool cgo is not really intended to be called directly by Go users: generally one is expected to use go build instead.

I think that, regardless of this, it would be a better default. The fact that it's racy by default does not seem to be documented anywhere for people that aren't typical Go users, and there are various workarounds to the left-over _obj directories being left over in various places. Examples from this repo include the gitignore file and bug #2693.

If this proposal is not accepted, then two potentially less controversial fixes (which would be addressed by this) still pop to mind:

• document the by-default racy nature of calling go tool cgo within same directory
• exit out early when the _obj directory is not successfully created because os.Mkdir fails

go tool cgo is not really intended to be called directly by Go users: generally one is expected to use go build instead.

I have file like this :

//go:build structs_gen

package mystructs

/*
#include "some_structs.h" // It only defines simplistic C structs
*/
import "C"

//go:generate sh -c "go tool cgo -godefs mystructs_gen.go > mystructs_def.go"
//go:generate rm _obj/_cgo_.o
//go:generate rmdir _obj

type myStructA C.struct_structA
type myStructB C.struct_structB
type myStructC C.struct_structC

I do that because after 6 years, my IDE (GoLand) still doesn't offers completion to C structs. (neither on C.struct_* nor on their type aliases)

So I workaround this sorry state by //go:build-ignoring the very .go file which would "import" the C structs declaration/definitions to the Go package,

And instead I call go generate -tags structs_gen whenever I need to refresh the Go "import", which generate a .go file which the IDE takes into account (which would roughly be the same than the one auto-generated by go run/build, but for which the IDE would not account).

Doing so leaves a (not temporary) _obj/ + _obj/cgo.o file, which I rm with further //go:generate rm .... commands.

So, anyway, that's an use case for possibly not having a (persistent by default) _obj/ directory placed in the source tree.

Best Regards,

I had a similar issue and a similar solution, though with a dedicated code parsing tool.
cgo code is seemingly simply just not parsed at all by golang.org/x/tools/go/packages (returning just errors), perhaps with #21712 as the root cause.

Though gopls under VS Code seems to understand cgo definitions just fine, and I never really thought to look into how it did it...

Change https://go.dev/cl/548076 mentions this issue: cmd/cgo: create temporary objdir by default