misc/cgo/fortran, cmd/dist: Fortran Support Causing go/src/all.bash to Fail #14544
Comments
mikioh
changed the title
|
This occurs on the dragonfly buildbot too. See http://build.golang.org/log/c10562643cfb4e429ca1f269dc0823bc76e830cf. /cc @kortschak |
|
This is curious - if it's not building it should not run the test. @odysseus9672 @mikioh before you do the operations below, there is an omission to my last CL that might help figure this out. Is there a main.exe in misc/cgo/fortran? If there is, what does it do when run? Then, can you tell me the outcome of running the test.bash in misc/cgo/fortran with $FC (the name of your fortran compiler) as a parameter? Also for |
|
Negative. This is the contents of misc/cgo/fortran/ . Here are the results of the experiments you wanted run: I wonder if this is because some environment variables aren't correctly being set in the test.bash file? |
|
Not "echo Can you echo $FC after it's set in the in misc/cgo/fortran/test.bash, and change "set -e" to "set -ex" and run all.bash paste the stanza regarding the fortran test here. |
|
I'll run your tests as soon as I describe the tests I've tried. I've set out testing things in test.bash, and I can only suppose that there is something hinky with the version of bash used on Mac OS X and Dragonfly. I tried adding the LDFLAGS to the test.bash script explicitly, and even sourcing Fink's init script, and the result is the same. Stranger still, the output of adding the verbose flag to the test script and running a verbose build outside of the script has virtually the same output. |
|
Can you remove the "rm -f main.exe" (this was just added today) from the test.bash file and run all.bash, then tell me if main.exe exists in misc/cgo/fortran at the end of the install?
|
|
Modifying fortran.go to read as follows works: Of course, making that change is not a general solution, but there should be some way to get the appropriate information setup. |
|
The output you asked for: main.exe exists and runs correctly. output from all.bash: |
|
Setting the environment variable CGO_LDFLAGS, as described here: also makes all.bash run correctly. So, I imagine that Fortran will need a CGO_FORTRANFLAGS, and CGO_LDFLAGS will suffice. |
|
Thanks. So it seems your gfortran knows where the libraries are when invoked from bash, but not from Go. Do you have any env vars that might be helping it?
One last thing you could do is to checkout the patch set 2 changes from https://golang.org/cl/19874 and see if all.bash passes. Don't give it any help with CGO_LDFLAGS.
|
|
I might have some environment variables set that help it. I can't identify which one, though, because none of them point to /sw/lib in a way that gfortran should understand. Edit: also, I'm up to the minute on the devel branch. |
|
@odysseus9672 would you please try |
|
The exit status changed, but nothing else I can see. |
|
I'm at a stage where I don't think I can take this further without access to a failing system to play with (I'm on linux here). Clearly the issue is that invoking gfortran minimally as it is done by test.bash does not fail when it should and so thinks it can proceed. What might be helpful is to report what go/build is passing to execute when gfortran is called via cgo. diff --git a/src/cmd/go/build.go b/src/cmd/go/build.go
index 89ab1c0..ff7574d 100644
--- a/src/cmd/go/build.go
+++ b/src/cmd/go/build.go
@@ -2044,6 +2044,11 @@ func (b *builder) runOut(dir string, desc string, env []string, cmdargs ...inter
}
}
+ if cmdline[0] == "gfortran" {
+ fmt.Println(cmdline)
+ fmt.Println(mergeEnvLists(env, envForDir(dir, os.Environ())))
+ }
+
nbusy := 0
for {
var buf bytes.BufferThen play with gfortran invocations for helloworld.f90 using the options that are passed until you get a helloworld.f90 build failure (also considering env vars). |
|
JFYI, I'm seeing the same error, also on OS X, but with gcc installed from Homebrew (which provides I applied the patch shown above and I got this: |
|
I've also applied the patch mentioned, and here's the output. |
|
BTW, if I throw a We can see that If I re-run the test as shown above but I override the environment variables You could argue that this setup is messed up ("what, your default C compiler is completely unrelated to your FORTRAN compiler?!") but since this is going to be a common problem given the number of people using Fink / MacPorts / Homebrew, it would be nice to find a way to fix this. Potentially using something along the lines of Since we're in 2016 and I personally couldn't care less about FORTRAN, I simply removed |
|
I'd prefer to have it detect the failure and skip rather than work hard to make the test pass. Any suggestion to how to get the attempt to build helloworld.f90 to fail on your machine in the same way? |
|
You'd have to better emulate the process used in the go build. For instance, have gfortran put out an object file and then have the linker try to make main.exe. Another possibility would be to test if the gfortran lib search dirs are contained in the search dirs used by the linker CGo is associated with or in the CGO_LDFLAGS. Though with the search dirs allowed to contain .. symbols, and probably symlinks, you'd need access to something that is more than a simple textual compare. The trouble is that it seems like requiring the Fortran compiler be part of the software package used for the C linker is excessively strict. |
Updates #14544. Change-Id: I24ab8e6f9ad9d290a672216fc2f50f78c3ed8812 Reviewed-on: https://go-review.googlesource.com/21014 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
./all.bash fails with the "/usr/bin/ld: cannot find -lgfortran" error on freebsd 10.2 too as soon as i (pkg) install gcc. |
|
CL https://golang.org/cl/21188 mentions this issue. |
|
I think this is a general problem, not a FreeBSD problem (not a dragonfly problem, for that matter). See #14544. |
|
Yup, but I'm fine to disable the flaky test until someone resolves the root cause. |
|
Then let's disable for everyone rather than adding OSes one at a time, since it has nothing to with the OS. |
|
Can we leave linux-amd64 to avoid gross regressions? With a TODO. |
|
Seems like the problem arises because if Could you see if https://golang.org/cl/21201 fixes the problem for you? |
|
Just reverted cmd/dist/test.go and gave a sho Perhaps we need to test the capability for |
|
CL https://golang.org/cl/21201 mentions this issue. |
|
CL21201 also fails on freebsd. If i manually run /usr/local/bin/gfortran helloworld/helloworld.f90 -o main.exe -lgfortran Not sure if this is related: |
|
@martisch Could you add |
|
@tsuna already mentioned a solution that sounded pretty workable, to me.
I added caveats about how it would be nice to prune the output from the Edit: I should add that I don't see this as a way to fix the test. I see it as a way to fix how cgo supports fortran. |
|
@ianlancetaylor sure, thanks for having a look at this. Seems cgo uses clang which is the default compiler in the freebsd base system and that clang wont find -lgfortran. The $FC command uses /usr/local/bin/gfortran. |
|
Hi, if I understand things correctly, I guess the solution is already clear. We can modify These values are defined by If $FC and defaultFC are empty, the misc/cgo/fortran test should be skipped. This solution is not only solving the issue, but also open for future extensions. |
|
Please try https://golang.org/cl/21297. |
|
CL https://golang.org/cl/21297 mentions this issue. |
|
with patch: |
|
@martisch If you set LD_LIBRARY_PATH correctly prior to all.bash, do you get success? |
|
I'm experiencing this general issue on FreeBSD 9.3, but there is a significant complication in my environment (one that may well exist in others). The short version is that I believe a fundamental problem here is compiling the Fortran code with gfortran (part of gcc) but compiling C code and linking everything with clang. Run straight, without the CL change to misc/cgo/fortran/test.bash, I get the same failure as others: However, with the modification to test.bash from CL https://golang.org/cl/21297 what I get instead is a failure to link: What I believe the underlying problem here is that on my FreeBSD the Fortran compiler is gfortran, ie GNU Fortran from the GCC compiler suite, but 'go test' is trying to build C code with clang and link the resulting clang C .o's with gfortran-compiled Fortran .o's. I'm not certain if this can ever work, but if it does it clearly needs more than just libgfortran.so itself, because libgfortran.so depends on libgcc_s.so and possibly other gcc-built shared libraries: I have tried a modification to the CL where I set not just It's possible that forcing use of gcc will deal with most of the issues here. The current test.bash diff I'm testing with is: |
|
got it to work adding to patchset 3: export CGO_LDFLAGS="-L /usr/local/lib/gcc48 -rpath /usr/local/lib/gcc48/" the path /usr/local/lib/gcc48 is the path reported by |
|
CL https://golang.org/cl/22730 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
go version)?go version
go version devel +7da4ced Sat Feb 27 21:12:19 2016 +0000 darwin/amd64
go env)?go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH=""
GORACE=""
GOROOT="/Users/sean/goLang/go"
GOTOOLDIR="/Users/sean/goLang/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
(Use play.golang.org to provide a runnable example, if possible.)
Run $GOROOT/src/all.bash
A successful build and run of the test suite.
The root of the problem is that the gfortran I use is supplied by the Fink software distribution (gcc5 package). Because of that, I need to find a way to get this into the LDFLAGS for the build process: -L/sw/lib/gcc5/lib
I've tried setting the environment variable before running all.bash, and that doesn't help. Ideally, there should three options that can be passed in to the build process to address this issue:
1: an explicit path to the fortran compiler to use,
2: the linker flag for things that need the standard fortran libs, and
3: a flag to disable the fortran feature if it isn't desired.
Maybe a set of environment variables (eg. GoFortran, GoFortranLibDir), where the fortran feature only kicks in if the first is set to the path of the fortran compiler and the second is a (list of?) directories to include in the linker's search space for fortran related builds.
The text was updated successfully, but these errors were encountered: