cmd/go: compilation order of fortran files is significant

[ctessum]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.9 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="{....}"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build881373539=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

I would like to build a go package that includes fortran source code files, similar to https://github.com/golang/go/tree/master/misc/cgo/fortran. The important difference from this example is that the package that I would like to compile includes fortran modules, for example:

package.go // depends on code in a_subroutine.f90
a_subroutine.f90 // depends on code in b_module.f90
b_module.90 

I would expect to be able to compile this with go build.

What did you expect to see?

successful compilation.

What did you see instead?

# {...}
<command-line>:12:6:

Fatal Error: Can't open module file ‘b_module.mod’ for reading at (1): No such file or directory

I think the problem might be that the order that fortran files are fed into the compiler is significant, and the go tool does not appear to account for this.

Potential fixes for this problem:

1. renaming all of the fortran files in the directory so that their alphabetical order is also their required compilation order. While this (usually?) works, it appears to depend on undocumented behavior.
2. resolving the fortran dependencies and figuring out the file order within the go tool. This seems unlikely to happen.
3. Allowing the specification of files to be compiled (and their order) a la cgo: Nowhere to specify C/C++ source files #12953.
4. Others?

[ianlancetaylor]

The go tool is not designed to be an all-purpose build system.

[ctessum]

Thank you for your response. I understand that it is not meant to be an all-purpose build tool. I think that most people that propose changes or new features understand that. Would it make sense to document that files are fed into the compiler in alphabetical order, because in this case that is an important detail? Can it be counted on that this behavior will not change in future releases? Or is it something that should not be depended on?

…

On Thu, Aug 24, 2017, 9:42 PM Ian Lance Taylor ***@***.***> wrote: The go tool is not designed to be an all-purpose build system. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21605 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF6AAUMIkQNcj1Aw9rLdFnjZUAshOBBzks5sblCcgaJpZM4PCNBn> .

[ianlancetaylor]

Interesting question. Guaranteeing alphabetical order is not a problem, but at least for C code we would not want to guarantee that the compilations do not occur in parallel. Perhaps for Fortran we could make an exception and serialize the compilations. But that might give us some extra complexity for a very unusual use case.

[ctessum]

I'm not an expert, but wouldn't the parallel compilation happen within whatever external tool the files are being fed into (e.g., gcc, gfortran), and not within the go tool itself?

…

On Thu, Aug 24, 2017, 10:16 PM Ian Lance Taylor ***@***.***> wrote: Interesting question. Guaranteeing alphabetical order is not a problem, but at least for C code we would not want to guarantee that the compilations do not occur in parallel. Perhaps for Fortran we could make an exception and serialize the compilations. But that might give us some extra complexity for a very unusual use case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21605 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF6AAQXSaMld4u1YNz5j4Nh616m1823qks5sblidgaJpZM4PCNBn> .

[ianlancetaylor]

The go tool effectively spawns separate processes gfortran -c a.f, gfortran -c b.f, gfortran -c c.f. Right now it does them in serial, but in the future it might start them all at the same time. That will work fine for C or C++, but, apparently, not for Fortran.