code review 6465060: misc/cgo/life: remove -lmsvcrt to fix windows/amd64 build

misc/cgo/life: remove -lmsvcrt to fix windows/amd64 build
        I guess this is the problem as I can't reproduce the failure.

[minux1, 2012-08-16 20:19:49]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[minux1, 2012-08-16 20:22:51]

could someone who can reproduce this problem help me test this CL?

[brainman, 2012-08-17 00:39:20]

On 2012/08/16 20:22:51, minux wrote:
> could someone who can reproduce this problem help me test this CL?

I can see different error when building tip misc/cgo/life - test program
crashes. And your change fixes that. So, I say it LGTM, lets submit and see.

On the other hand, 386 builder fails for different reason (see the output). I
think, we have hit http://code.google.com/p/go/issues/detail?id=3358 again. I
guess we should disable test at fault (as we did for other test) for now (in a
later CL). I do not know how to tackle
http://code.google.com/p/go/issues/detail?id=3358, so, perhaps, we should come
up with a way to cheat and make these test work in a builder. I will think about
that.

Alex

[minux1, 2012-08-17 01:10:26]

*** Submitted as http://code.google.com/p/go/source/detail?r=833bc91ca720 ***

misc/cgo/life: remove -lmsvcrt to fix windows/amd64 build
        I guess this is the problem as I can't reproduce the failure.

R=golang-dev, alex.brainman
CC=golang-dev
http://codereview.appspot.com/6465060

[minux1, 2012-08-17 16:00:59]

On Fri, Aug 17, 2012 at 8:39 AM, <alex.brainman@gmail.com> wrote:

> On the other hand, 386 builder fails for different reason (see the
> output). I think, we have hit
>
http://code.google.com/p/go/**issues/detail?id=3358<http://code.google.com/p/....
I guess we
> should disable test at fault (as we did for other test) for now (in a
> later CL). I do not know how to tackle
>
http://code.google.com/p/go/**issues/detail?id=3358<http://code.google.com/p/...,
> so, perhaps, we
> should come up with a way to cheat and make these test work in a
> builder. I will think about that.
>
can we shorten the path of the builder's temporary directory?
change it to C:\t might help, as the complete path of it appears several
times
in the offending path.

[brainman, 2012-08-18 07:42:25]

On 2012/08/17 16:00:59, minux wrote:
> >
> can we shorten the path of the builder's temporary directory?
> change it to C:\t might help,

Certainly. I think gobuilder has flag where we can specify that directory
instead of TEMP. But then we have to rely on people how run gobuilder to
remember that.

> ... as the complete path of it appears several
> times
> in the offending path.

Yes, I was trying to refresh my memory the other day about why go command use
import paths that have double of absolute path. Perhaps, we can change that
logic. Forget gobuilder, I am more concerned about people using long GOPATH
(like "c:\Document and Settings ...") together with long import paths (like
"code.google.com/p/...").

Alex

[brainman, 2012-08-27 02:27:21]

On 2012/08/18 07:42:25, brainman wrote:
> 
> Yes, I was trying to refresh my memory the other day about why go command use
> import paths that have double of absolute path. ...

Looked again, and here is how it works.

For directories outside of GOPATH it uses package directory absolute path as
import path. Sounds sensible to me. Really it needs to be unique, but, if you
are building more then one package in one command, then these should have
separate import paths. We can use short hash of full path instead, but using
absolute paths also makes it easy to reason about them.

During tests, go command creates special test package that is different from
tested package in a way that it includes *_test.go files. This package is
treated as separate package and is copied into _test directory under package
directory. So, for example, for package unicode/utf8 we create both
$WORK/unicode/utf8.a and $WORK/unicode/utf8/_test/unicode/utf8.a (contains test
version of the package). I tried moving it into $WORK/_test/unicode/utf8.a
instead, and it works for our case, but it also breaks when multiple packages
are tested in one command. So, as before, _test directory is not good enough, it
needs to be unique. So keeping those in a privacy of package directory sounds
reasonable.

I have not found a good solution. But, on the other hand, I discovered that part
of our problem is that we are running outside of GOPATH. Our scenario is
special.

I think, we should use directory with short absolute path on our go builder, as
you suggested. If we could rely on builder owners to set it up correctly, we
could just use -buildroot go builder flag to specify that. Alternatively, we
could change go builder to use "c:\" as default build root on windows.

Lets wait for Russ before we make decision.

Alex