This is happening because we add -I . to the C compiler argument list, as explained at https://golang.org/src/cmd/cgo/util.go#L40. I'm not sure offhand how to fix it.

Oh. Well, for GCC, I think this could be fixed by using -iquote . instead of -I .

Directories specified with -iquote apply only to the quote form of the directive, #include "file".

https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

Clang also seems to support -iquote, at a glance. Not sure what other C compilers cgo is supposed to be able to work with though.

@ianlancetaylor I did some more research into this issue and I think it should be closed, because it turns out to be a breaking change (and not just theoretically).

I started by putting together a patch that changed -I . to -iquote . in a couple of places:

% git diff
diff --git a/src/cmd/cgo/util.go b/src/cmd/cgo/util.go
index 921306b7aa..0efd26ff68 100644
--- a/src/cmd/cgo/util.go
+++ b/src/cmd/cgo/util.go
@@ -45,7 +45,7 @@ func run(stdin []byte, argv []string) (stdout, stderr []byte, ok bool) {
                // We've also run into compilers that reject "-I." but allow "-I", ".",
                // so be sure to use two arguments.
                // This matters mainly for people invoking cgo -godefs by hand.
-               new = append(new, "-I", ".")
+               new = append(new, "-iquote", ".")
 
                // Finish argument list with path to C file.
                new = append(new, name+".c")
diff --git a/src/cmd/go/internal/work/exec.go b/src/cmd/go/internal/work/exec.go
index d975c36306..a6bb298781 100644
--- a/src/cmd/go/internal/work/exec.go
+++ b/src/cmd/go/internal/work/exec.go
@@ -2363,7 +2363,7 @@ func (b *Builder) compilerExe(envValue string, def string) []string {
 func (b *Builder) compilerCmd(compiler []string, incdir, workdir string) []string {
        // NOTE: env.go's mkEnv knows that the first three
        // strings returned are "gcc", "-I", incdir (and cuts them off).
-       a := []string{compiler[0], "-I", incdir}
+       a := []string{compiler[0], "-iquote", incdir}
        a = append(a, compiler[1:]...)
 
        // Definitely want -fPIC but on Windows gcc complains

That makes my test case work the way I expected (once I'd worked out I needed to invoke go clean -cache when debugging cgo like this - trick for new players 😂 )

Then, I ran the test suite against this. There was one failure, from TestCgo in go/internal/srcimporter. The failure was caused by this line in misc/cgo/test/test.go

// issue 4339
// We've historically permitted #include <>, so test it here.  Issue 29333.
#include <issue4339.h>

Since I'd changed the -I flags to -iquote, this obviously stopped working since the import is looking for a file in the current directory, without quotes.

I looked at these issues - #4339 just happens to be the header that's being included, but #29333 ("cmd/cgo: can not include header file in package directory with Go 1.12beta1") is relevant. Someone noticed that the cgo build of the module crawshaw.io/sqlite had stopped working, because someone had accidently stopped the -I . flag getting appended on the call to run in eeb8aeb, and you personally fixed this in d9e2ba4 and added this explicit test for this behaviour.

tl;dr - being able to include files from the current directory with #include<> is explicitly tested for, and something that at least somebody in the wild is doing, and it would cause some breakage to fix this even though on its own this behaviour seems pretty wrong to me (and stops use-cases like the bundled/dynamic switch like I mentioned in my original report).

Can you see a viable path forward here? At the very least, I figure there should be a warning in the cgo docs about the include path working this way - I'm happy to send a CL to add it if you think that's the way we should go.

Thanks for doing the investigation. It does seem that we aren't going to be able to change this.

I agree that this should be documented somewhere in cmd/cgo/doc.go.

Perhaps you can solve your original problem using a #cgo CFLAGS: -DUSE_LOCAL_HEADER, and rename the header file that everything includes, and do something like

#ifdef USE_LOCAL_HEADERS
    local definitions
#else
#include <real-header-name.h>
#endif

Change https://golang.org/cl/251758 mentions this issue: cmd/cgo: document #include <> search path behaviour

Thanks for the suggestion - putting a define in the CFLAGS sounds like a good option for fixing my original problem.

I've sent a patch to document what's going on ☝️