gb rebuilds stdlib every build

[Redundancy]

I'm having an issue where gb rebuilds the stdlib every time I build my project since I updated to Golang 1.6 on windows by using the windows installer. I've updated gb and rebuilt it manually, but this doesn't seem to matter.

[davecheney]

This is usually caused by an incorrect go installation, or because gb is
older than your go installation.

Can you please post the output of gb info and also run your build with

DEBUG=1

Set and post the complete output, it should be simple to figure it out from
there.

On Wed, 24 Feb 2016, 03:38 Daniel Speed notifications@github.com wrote:

I'm having an issue where gb rebuilds the stdlib every time I build my
project since I updated to Golang 1.6 on windows by using the windows
installer. I've updated gb and rebuilt it manually, but this doesn't seem
to matter.

—
Reply to this email directly or view it on GitHub
#570.

[Redundancy]

C:\Users\Dan\Dropbox\project\crest>gb info GB_PROJECT_DIR="C:\Users\Dan\Dropbox\project\crest" GB_SRC_PATH="C:\Users\Dan\Dropbox\project\crest\src;C:\Users\Dan\Dropbox\project\crest\vendor\src" GB_PKG_DIR="C:\Users\Dan\Dropbox\project\crest\pkg\windows-amd64" GB_BIN_SUFFIX="-windows-amd64" GB_GOROOT="C:\Go\"

Note that I've uninstalled Go 1.6, ensured that the directory is clean, rebuilt gb and gb-vendor with build -a.

debug.txt

[Redundancy]

2016/02/24 21:43:08 install.go:107: C:\Go\pkg\windows_amd64\runtime.a is older than C:\Go\pkg\windows_amd64\runtime\internal\sys.a

The modified timestamp on runtime.a is 17/02/2016 20:36 and sys.a is 20:42
Since I emptied the directory and reinstalled, I assume that these timestamps are from the win64 installer.

[davecheney]

Urgh, so the go distribution is wrong. The osx installer also had this
problem, but we fixed it before the 1.6 release.

On Thu, 25 Feb 2016, 08:59 Daniel Speed notifications@github.com wrote:

2016/02/24 21:43:08 install.go:107: C:\Go\pkg\windows_amd64\runtime.a is
older than C:\Go\pkg\windows_amd64\runtime\internal\sys.a

The modified timestamp on runtime.a is 17/02/2016 20:36 and sys.a is 20:42
Since I emptied the directory and reinstalled, I assume that these
timestamps are from the win64 installer.

—
Reply to this email directly or view it on GitHub
#570 (comment).

[Redundancy]

Perhaps the odd thing here is that having decided to recompile the standard packages once to the local pkg folder, it doesn't pick up those when looking at the timing, and decides to do it again.

[davecheney]

There is a lot of complicated logic that goes on to decide when to rebuild
the standard library, and where to look for it if you are or are not cross
compiling. I'll put a rule in place that says never rebuild the standard
library if not cross compiling. That seems like the shortest way to a
solution given how many Go installations are silently broken like this.

On Thu, Feb 25, 2016 at 9:30 AM, Daniel Speed notifications@github.com
wrote:

Perhaps the odd thing here is that having decided to recompile the
standard packages once to the local pkg folder, it doesn't pick up those
when looking at the timing, and decides to do it again.

—
Reply to this email directly or view it on GitHub
#570 (comment).

[wheineman]

I can confirm that when I touched the 'Go\pkg\windows_amd64\runtime\internal\sys.a' file to set it's date to match 'Go\pkg\windows_amd64\runtime.a', gb stopped rebuilding everything and worked as I expected (that is, only compiling things I had changed).

[lancecarlson]

Having this issue as well. Love the irony of your username in this case @Redundancy lol.

[davecheney]

@ALL, a fix for this issue landed in 673e8a6 and was included in to 0.4.0 release.

Can anyone who is having difficulties please confirm for me the revision of gb they are using, and include the output of their invocation with DEBUG=1 enabled. It will be easy to see from that output which file gb thinks it out of date.

[lancecarlson]

@davecheney I removed gb from my bin and src, ran go get github.com/constabulary/gb/...

gb build still rebuilding everytime. Output with debug:

https://gist.github.com/lancecarlson/b66a93189124478c48ce

[davecheney]

Can you please follow the upgrade instructions on the website; you're
missing the -u flag. By default go get does not pull from the remote if the
files exist on disk.

On Tue, 8 Mar 2016, 05:09 Lance Carlson, notifications@github.com wrote:

@davecheney https://github.com/davecheney I removed gb from my bin and
src, ran go get github.com/constabulary/gb/...

gb build still rebuilding everytime. Output with debug:

https://gist.github.com/lancecarlson/b66a93189124478c48ce

—
Reply to this email directly or view it on GitHub
#570 (comment).

[Redundancy]

I'm seeing the same thing:

E:\Dropbox\project\GoFiddle\src\github.com\constabulary\gb>git rev-parse HEAD
c00a5b4

using:
go get -u github.com/constabulary/gb/cmd/gb go build -a github.com/constabulary/gb/cmd/gb go build -a github.com/constabulary/gb/cmd/gb-vendor

still rebuilding the standard library.

[davecheney]

Please follow the upgrade instructions on the website. It's probably not
going to make that much of a difference, but it helps if everyone is
consistent.

On Tue, Mar 8, 2016 at 9:29 AM, Daniel Speed notifications@github.com
wrote:

I'm seeing the same thing:

E:\Dropbox\project\GoFiddle\src\github.com\constabulary\gb>git rev-parse
HEAD
c00a5b4
c00a5b4

using:

go get -u github.com/constabulary/gb/cmd/gb
go build -a github.com/constabulary/gb/cmd/gb
go build -a github.com/constabulary/gb/cmd/gb-vendor

still rebuilding the standard library.

—
Reply to this email directly or view it on GitHub
#570 (comment).

[davecheney]

Also, please follow the debugging instructions above and post your results.
Thanks

On Tue, Mar 8, 2016 at 9:33 AM, Dave Cheney dave@cheney.net wrote:

Please follow the upgrade instructions on the website. It's probably not
going to make that much of a difference, but it helps if everyone is
consistent.

On Tue, Mar 8, 2016 at 9:29 AM, Daniel Speed notifications@github.com
wrote:

I'm seeing the same thing:

E:\Dropbox\project\GoFiddle\src\github.com\constabulary\gb>git rev-parse
HEAD
c00a5b4
c00a5b4

using:

go get -u github.com/constabulary/gb/cmd/gb
go build -a github.com/constabulary/gb/cmd/gb
go build -a github.com/constabulary/gb/cmd/gb-vendor

still rebuilding the standard library.

—
Reply to this email directly or view it on GitHub
#570 (comment).

[Redundancy]

log2.txt

Note that if I just do go get -u, I don't tend to get a gb-vendor build.

[davecheney]

The problem you are seeing was fixed before 0.4.0, please follow the upgrade instructions, https://getgb.io/docs/install/ Then please check that the version of gb.exe that was rebuilt is the one you expect, I've had multiple reports of people using old versions of gb that they copied somewhere else in their path taking precedence.

[Redundancy]

At least as far as I can see, the trigger is still:
install.go:107: C:\Go\pkg\windows_amd64\runtime.a is older than C:\Go\pkg\windows_amd64\runtime\internal\sys.a

That dependency check takes place and returns before the change on line 119 can be hit. It returns true way before it can work out it shouldn't.

[davecheney]

Thank you. I'll push a fix right now for that.

On Tue, Mar 8, 2016 at 10:02 AM, Daniel Speed notifications@github.com
wrote:

At least as far as I can see, the trigger is still:
install.go:107: C:\Go\pkg\windows_amd64\runtime.a is older than
C:\Go\pkg\windows_amd64\runtime\internal\sys.a

That dependency check takes place and returns before the change on line
119 can be hit. It returns true way before it can work out it shouldn't.

—
Reply to this email directly or view it on GitHub
#570 (comment).