Comment 1:

Labels changed: added os-windows.

Owner changed to @alexbrainman.

Status changed to Accepted.

Comment 3:

Labels changed: added priority-later, removed priority-medium.

Comment 4:

Labels changed: added priority-go1.

Comment 5:

Owner changed to builder@golang.org.

Comment 6 by vcc.163:

8l: emit resources (.rsrc) in Windows PE.
http://code.google.com/p/go/source/detail?r=99a520c00dcf8231ee1ed8c69137e61b435663d6&path=/src/cmd/ld/ldpe.c
This issue should fixed.

Comment 7:

Nice, thanks.  We still need a way to hook this up.

Comment 8:

It looks like the ldpe support requires that the resource have been generated in a PE
object, meaning it was compiled from a C file during a build of a cgo package.  Is that
right?  Is that all we need?

Comment 9:

windres produce pe object file out of "resource" file (text file describing all its and
pieces). Then resulting object is linked to the final executable using 8l.exe.
Alex

Comment 10:

does this work with the go tool? how?

Comment 11:

I do not think it would. Even if, lets say, you prebuild object file with resources (by
using windres in one way or the other), how would you ask go to peek that object file
and link it as part of an exe. Without make file it is.
Alex

Comment 12:

We could say that if the .o file is sitting in the directory,
we add it to the archive, just as you used to do by
adding it to the OFILES list in the Makefile.

Comment 13:

I think, assuming that every .o file has to be part of an exe is a bit forceful. You
could go ahead with this idea. But with pe file, you could add sections after it is
built. So we can always creat tool that would add resources after. We could just use
make like before for these. We could write some sort of compiler that builds resources
out of source files. It is hard for me to see the use case until I actually do something
like that.
Alex

Comment 14:

But the GNU windres program is already a compiler that builds resources out of source
files.  Hard to see why we would need another one.  (Although when I wrote windres I
designed it so that it could generate various different output formats, and that still
seems to be true.)
This is another example of a tool like goyacc that generates an output file that should
be included in the program, although in this case the tool generates an object file
rather than Go source code.  If we have a reasonable way to handle generated files, it
should handle this case too.
In the meantime, gathering all .o files into the link sounds a bit error-prone to me,
but we could use a different extension--.ogo?--or we could list them in a //build
comment.

Comment 15:

It would be nice if (1) the solution worked for clients of a package that needs a
resource without adding a new tool that all clients must have and (2) the solution was a
little more general than Windows resources.  I believe that it will work for both gccgo
and 6g if we can just get the object file into the package file, like we used to with
the Makefile OFILES list.
Perhaps .syso could be the extension for system object files that should be copied into
the package archive?
It is tempting (but unreasonable) to use .goo instead.

Comment 16:

This issue was closed by revision b099633.

Status changed to Fixed.