Closed baconalot closed 9 years ago
mmm, fixed it by adding the goroot/bin to /etc/environment, but I am still curious in what user context oracle runs here...
@baconalot : I have the same error. Could you explain how you fixed the issue? How do I add goroot/bin to /etc/environment?
@croman linux only;
I think it's worth reopening this as I'm seeing the same problem on OSX Yosemite and I've struggled to get my path set correctly in Eclipse.
I eventually hacked round it by symlinking /usr/bin/go -> /usr/local/go/bin/go
, but it feels like this should work out of the box as I've got my GOPATH
correctly configured in GoClipse.
The error above seems to be about PATH, not GOPATH : go": executable file not found in $PATH
.
Goclipse runs the Oracle tool with a modified GOPATH, but it doesn't modify the PATH env var, so go
needs to be on the PATH. (Hum, I guess Goclipse could handle this better and modify the PATH too)
I think I confused the issue mentioning GOPATH
. go
is on my PATH
and runs happily within my terminal, however GoClipse seems to be getting a different PATH
, and I'm not sure where it's coming from.
I tried a few things mentioned in relation to modifying the PATH
for Eclipse specifically and OSX in general, however the things I tried didn't solve the problem, hence resorting to hacking in a symlink to somewhere that was on the PATH
.
I've also realised that I meant GOROOT
rather than GOPATH
. The reason I mentioned GOROOT
is GoClipse is aware of it and from there could work out where go
is, although there may be other better solutions.
I could make it so that Go oracle is started with a PATH that includes GOROOT. I'm not sure I want to though, as I can argue that I don't want the Oracle user environment to be that different to what it is when started manually on the command line. One could even argue that oracle could figure this out itself, by looking at GOROOT.
Unfortunately OSX provides a different environment to command line apps, e.g. oracle
and apps launched via the UI, e.g. eclipse
.
I agree the best solution would be for oracle
to look at GOROOT
, this makes a lot of sense.
Pragmatically, starting oracle
with a PATH
that has GOROOT
appended shouldn't cause any problems, as earlier entries on the path will take precedence if set. It should just be providing a fallback and is likely to save people running into the same issue I did, so I'd be in favour of doing this as a workaround.
Unfortunately OSX provides a different environment to command line apps, e.g. oracle and apps launched via the UI, e.g. eclipse.
Can you explain this in more detail, as I'm not familiar with OSX?
I'll try!
Opening a terminal behaves like other _NIX systems and reads the expected _profile
files setting up environment in the usual way. This is where I have mygo
environment variables set up. Everything works great when running from the terminal.
Applications that are launched from the OSX UI however behave differently. As I understand it, and I suspect my understanding isn't perfect or I would've been able to resolve the issue better, the parent process isn't a login shell. This means that environment variables aren't set up in the same way and therefore aren't there to be inherited by child processes. In theory you can control the environment of GUI apps by other means, however this seems to differ between OSX versions and there's no consistent way to have the same consistent environment between shell and UI. The result of this is threads on stack overflow trying a frenzy of different configuration permutations in unsuccessful attempts to get it to work (I visited that thread myself before just symlinking the offending binary onto my path as GUI apps see it).
I agree that goclipse definitely isn't at fault here and that it's a pain to work round problems in other apps rather than them being fixed upstream but, pragmatically, putting a fix in goclipse is likely to save people some time along the line and, I think, is unlikely to have any side-affects.
I've just tried (on Windows) to run oracle without GOROOT being in the PATH - it ran without problems, as long as GOROOT was correctly set on Goclipse. This seems to indicate GOROOT does not need to be in the PATH, can you recheck the problem on your machine, with the latest oracle? Perhaps the issue is another.
Here's what I'm seeing:
cgo failed: [go tool cgo -objdir /var/folders/l0/pv117v_16rsbrzrn4d8pd9740000gq/T/net_C948571759 -- -I /var/folders/l0/pv117v_16rsbrzrn4d8pd9740000gq/T/net_C948571759 cgo_bsd.go cgo_unix.go]: exec: "go": executable file not found in $PATH
GoClipse has the correct configuration for both GOROOT
and GOPATH
Hum, is it the latest oracle?
Yup. To check I removed it and ran go get golang.org/x/tools/cmd/oracle
and re-ran the above tests. Same results.
That's strange, but ok, added: #113
I'm having the same issue with Yosemite and can confirm @nickpeirson comments.
I get an error (Program exited with non-zero status:1) when I invoke "Open definition (go oracle)" anywhere in my code base. (goclipse 0.9.1) The output in the "Oracle/gocode log":
When I run the oracle call in a terminal it runs fine. I don't know if eclipse forks another bash, that does not have the path to 'go'.