code review 5778043: go/build, cmd/go: add support for .syso files

go/build, cmd/go: add support for .syso files

.syso files are system objects copied directly
into the package archive.

Fixes issue 1552.

[rsc, 2012-03-07 19:09:05]

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

I'd like you to review this change to
https://go.googlecode.com/hg/

[r, 2012-03-07 21:23:41]

LGTM

[minux1, 2012-03-07 21:38:54]

Hi Russ,

Given that go can handle extern object files, may I ask if cmd/go could
provide a means
to expose the CFLAGS needed for gcc to compile the external object files?

I think this ability will be useful, esp. considering misc/cgo/testso,
where it must know
what CFLAGS/LDFLAGS cmd/go use to compile gcc object files.
(I don't want to repeat the logic in cmd/go in another place.)

[remyoudompheng, 2012-03-07 21:44:30]

Le 7 mars 2012 22:38, minux <minux.ma@gmail.com> a écrit :
> Hi Russ,
>
> Given that go can handle extern object files, may I ask if cmd/go could
> provide a means
> to expose the CFLAGS needed for gcc to compile the external object files?
>
> I think this ability will be useful, esp. considering misc/cgo/testso, where
> it must know
> what CFLAGS/LDFLAGS cmd/go use to compile gcc object files.
> (I don't want to repeat the logic in cmd/go in another place.)

I think objects are just linked, not compiled, what are you referring to?

Rémy.

[minux1, 2012-03-07 21:49:49]

On Thu, Mar 8, 2012 at 5:44 AM, Rémy Oudompheng <remyoudompheng@gmail.com>wrote:

> Le 7 mars 2012 22:38, minux <minux.ma@gmail.com> a écrit :
> > Given that go can handle extern object files, may I ask if cmd/go could
> > provide a means
> > to expose the CFLAGS needed for gcc to compile the external object files?
> >
> > I think this ability will be useful, esp. considering misc/cgo/testso,
> where
> > it must know
> > what CFLAGS/LDFLAGS cmd/go use to compile gcc object files.
> > (I don't want to repeat the logic in cmd/go in another place.)
>
> I think objects are just linked, not compiled, what are you referring to?

Where does these objects eventually come from?
Either they are from data file (e.g., resource for Windows), or compiled
from source
code. In the latter case, you will need the appropriate CFLAGS to compile
them to
be linkable by cmd/ld, right?

I ask where can I find these necessary information.

[rsc, 2012-03-07 22:05:44]

On Wed, Mar 7, 2012 at 16:38, minux <minux.ma@gmail.com> wrote:
> Given that go can handle extern object files, may I ask if cmd/go could
> provide a means
> to expose the CFLAGS needed for gcc to compile the external object files?
>
> I think this ability will be useful, esp. considering misc/cgo/testso, where
> it must know
> what CFLAGS/LDFLAGS cmd/go use to compile gcc object files.
> (I don't want to repeat the logic in cmd/go in another place.)

I think you are asking for something that would print

-m64 -pthread -fpic

if those are the flags that should be used when invoking
gcc to generate a go-compatible .o file.

I have been thinking about implementing a go env like go dist env
(but run by the go command, which can do more).  Maybe that
would be a place to print this information.

Russ

[minux1, 2012-03-07 22:10:08]

On Thu, Mar 8, 2012 at 6:05 AM, Russ Cox <rsc@golang.org> wrote:

> On Wed, Mar 7, 2012 at 16:38, minux <minux.ma@gmail.com> wrote:
> > Given that go can handle extern object files, may I ask if cmd/go could
> > provide a means
> > to expose the CFLAGS needed for gcc to compile the external object files?
> >
> > I think this ability will be useful, esp. considering misc/cgo/testso,
> where
> > it must know
> > what CFLAGS/LDFLAGS cmd/go use to compile gcc object files.
> > (I don't want to repeat the logic in cmd/go in another place.)
>
> I think you are asking for something that would print
>
> -m64 -pthread -fpic

Exactly. Once this info. is exported, misc/cgo/testso can be re-enabled.

>

 I have been thinking about implementing a go env like go dist env
> (but run by the go command, which can do more).  Maybe that
> would be a place to print this information.

This will have added benefit of removing CGO_ENABLED knowledge from
cmd/dist.
In run.bash, we can just 'eval $(go env)'.

[rsc, 2012-03-07 22:12:14]

That sounds reasonable.  I will add this in a separate CL.

[rsc, 2012-03-07 22:15:42]

On Wed, Mar 7, 2012 at 16:23, Rob 'Commander' Pike <r@golang.org> wrote:
> LGTM

Thanks.  Will wait to see if Ian has comments before submitting.

[iant, 2012-03-07 23:26:52]

LGTM

[brainman, 2012-03-08 01:52:04]

It is not building for me on windows or linux:

...
pkg/text/template/parse
pkg/text/template
pkg/go/doc
pkg/go/build
cmd/go
C:\MinGW\go\src\cmd\go\build.go:731: a.p.SysoFiles undefined (type *Package has
no field or method SysoFiles)
C:\MinGW\go\src\cmd\go\pkg.go:93: p.SysoFiles undefined (type *Package has no
field or method SysoFiles)
C:\MinGW\go\src\cmd\go\pkg.go:491: p.SysoFiles undefined (type *Package has no
field or method SysoFiles)
go tool dist: FAILED: C:\MinGW\go\pkg\tool\windows_386\8g -o
C:\DOCUME~1\brainman\LOCALS~1\Temp\go151.tmp\_go_.8 -p main
C:\MinGW\go\src\cmd\go\bootstrap.go C:\
MinGW\go\src\cmd\go\build.go C:\MinGW\go\src\cmd\go\clean.go
C:\MinGW\go\src\cmd\go\fix.go C:\MinGW\go\src\cmd\go\fmt.go
C:\MinGW\go\src\cmd\go\get.go C:\MinGW\go\src\cmd\go\help.go
C:\MinGW\go\src\cmd\go\list.go C:\MinGW\go\src\cmd\go\main.go
C:\MinGW\go\src\cmd\go\pkg.go C:\MinGW\go\src\cmd\go\run.go
C:\MinGW\go\src\cmd\go\test.go C:\MinGW\go\src\cmd\go\testflag.go
C:\MinGW\go\src\cmd\go\tool.go C:\MinGW\go\src\cmd\go\vcs.go
C:\MinGW\go\src\cmd\go\version.go C:\MinGW\go\src\cmd\go\vet.go

hg id = 57211062f289+

Alx

[rsc, 2012-03-08 03:03:22]

*** Submitted as 79896e3bc1f8 ***

go/build, cmd/go: add support for .syso files

.syso files are system objects copied directly
into the package archive.

Fixes issue 1552.

R=alex.brainman, iant, r, minux.ma, remyoudompheng
CC=golang-dev
http://codereview.appspot.com/5778043

[rsc, 2012-03-08 03:08:08]

On Wed, Mar 7, 2012 at 20:52,  <alex.brainman@gmail.com> wrote:
> It is not building for me on windows or linux:

Sorry, I think Rietveld had a slightly stale copy.