It would help to be more specific: different -buildmode options are, and always will be, supported on different systems. Which -buildmode options are you specifically interested in?

Probably, most of windows users are looking for a way to generate dlls.:

--buildmode=c-shared

or

--buildmode=dll

I only need -buildmode=c-shared, to generate DLL for other C/C++ user.
If Go can generate DLL, i can say byebye to C++.

PS: Also hope fix #9510 in Go1.5!

I would also like to see this happen. Is anyone currently working on this issue? Any CL's which may be reviewed?

I also need this. If I had some idea how much work was involved I might be willing to contribute an implementation. I know that Windows DLLs are fairly different from ELF style shared libraries, so if this is an enormous task it won't be something I can commit to.

Is there any way to find out how much/what kind of work would be involved?

@nadiasvertex The main thing is to make the function hostlink in cmd/link/internal/ld/lb.go do the right thing on Windows. On Darwin it invokes theC linker with -dynamiclib. On GNU/Linux it invokes the C linker with -Wl,-Bsymbolic -Wl,-z,relro -shared -Wl,-z,nodelete.

Basically, if you produce a list of commands that will turn a Windows object file into a Windows DLL, change hostlink to invokes those commands.

That said, it's possible that Windows needs to know the list of symbols that are callable from outside the DLL. It used to need to know that, but it's been many years since I looked at it. If you need that list of symbols, it's available by looping over the symbol table and looking for the Cgoexport field having a CgoExportStatic flag.

Great! I'll look at it. I suspect that the challenge is mostly in knowing
where the linker is on Windows.

On Mon, Dec 7, 2015 at 10:58 AM Ian Lance Taylor notifications@github.com
wrote:

@nadiasvertex https://github.com/nadiasvertex The main thing is to make
the function hostlink in cmd/link/internal/ld/lb.go do the right thing on
Windows. On Darwin it invokes theC linker with -dynamiclib. On GNU/Linux it
invokes the C linker with -Wl,-Bsymbolic -Wl,-z,relro -shared
-Wl,-z,nodelete.

Basically, if you produce a list of commands that will turn a Windows
object file into a Windows DLL, change hostlink to invokes those commands.

That said, it's possible that Windows needs to know the list of symbols
that are callable from outside the DLL. It used to need to know that, but
it's been many years since I looked at it. If you need that list of
symbols, it's available by looping over the symbol table and looking for
the Cgoexport field having a CgoExportStatic flag.

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

@ianlancetaylor I started looking into this a little more, and it turns out that I have some questions about some fundamental parts of the architecture. For example:

1. I see that building go on Windows appears to require a gcc-ish compiler, like mingw. Consequently, I assume that doing C archive building or shared library building would require the same thing (instead of, say, MSVC.)
2. So far I have enabled the commands for doing a go build with c-shared and I get "_rt0_amd64_windows_lib: not defined", which appears to be set in lib.go/libinit. I'm not entirely sure what to look for here, so some pointers would be helpful.

In case it is helpful, the current trace output looks like:

WORK=C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698
mkdir -p $WORK\command-line-arguments_obj
mkdir -p $WORK\command-line-arguments_obj\exe
cd Z:\projects\test\src\calc
CGO_LDFLAGS="-g" "-O2" "z:\projects\go\pkg\tool\windows_amd64\cgo.exe" -objdir "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj" -importpath command-line-arguments "-exportheader=C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_install.h" -- -I "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj" calc.go
gcc -I "Z:\projects\test\src\calc" -m64 -mthreads -fmessage-length=0 -print-libgcc-file-name
gcc -I "Z:\projects\test\src\calc" -m64 -mthreads -fmessage-length=0 -I "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj" -g -O2 -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_main.o" -c "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_main.c"
gcc -I "Z:\projects\test\src\calc" -m64 -mthreads -fmessage-length=0 -I "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj" -g -O2 -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_export.o" -c "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_export.c"
gcc -I "Z:\projects\test\src\calc" -m64 -mthreads -fmessage-length=0 -I "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj" -g -O2 -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj\calc.cgo2.o" -c "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj\calc.cgo2.c"
gcc -I "Z:\projects\test\src\calc" -m64 -mthreads -fmessage-length=0 -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_.o" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_main.o" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_export.o" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj\calc.cgo2.o" -g -O2
"z:\projects\go\pkg\tool\windows_amd64\cgo.exe" -objdir "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj" -dynpackage main -dynimport "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_.o" -dynout "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_import.go"
gcc -I "Z:\projects\test\src\calc" -m64 -mthreads -fmessage-length=0 -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_all.o" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_export.o" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj\calc.cgo2.o" -g -O2 -Wl,-r -nostdlib -Wl,--start-group -lmingwex -lmingw32 -Wl,--end-group C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/libgcc.a
"z:\projects\go\pkg\tool\windows_amd64\compile.exe" -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments.a" -trimpath "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698" -p main -buildid af4f2da53bc903b4d17a55032a8fca5f579d7452 -D /Z/projects/test/src/calc -I "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698" -pack "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_gotypes.go" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj\calc.cgo1.go" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_cgo_import.go"
pack r "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments.a" "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj_all.o" # internal
cd .
"z:\projects\go\pkg\tool\windows_amd64\link.exe" -o "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments_obj\exe\a.out.exe" -L "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698" -extld=gcc -buildmode=c-shared -buildid=af4f2da53bc903b4d17a55032a8fca5f579d7452 -v "C:\Users\CHRIST1\AppData\Local\Temp\go-build642482698\command-line-arguments.a"

command-line-arguments

HEADER = -H11 -T0x401000 -D0x0 -R0x1000
searching for runtime.a in $WORK/runtime.a
searching for runtime.a in z:\projects\go/pkg/windows_amd64/runtime.a
0.00 deadcode
0.01 pclntab=154410 bytes, funcdata total 33488 bytes
0.01 dodata
0.01 reloc
0.02 reloc
_rt0_amd64_windows_lib.ptr: _rt0_amd64_windows_lib: not defined
0.02 asmb
0.02 codeblk
0.03 datblk
0.03 sym
0.03 dwarf
0.03 headr
0.03 symsize = 0
0.03 symsize = 0
_rt0_amd64_windows_lib.ptr: undefined: _rt0_amd64_windows_lib

I don't think anybody we must require GCC, but clearly we do need some other toolchain. If somebody wants to add support for MSVC, I think that would be great. In any case, I think we do want to make it possible to suppose -buildmode=c-shared using GCC.

_rt0_amd64_windows_lib should be defined in runtime/rt0_windows_amd64.s, and should probably look something like _rt0_amd64_linux_lib in runtime/rt0_linux_amd64.s. I admit that I completely forgot about that part of this work. You'll have to tweak the argc/argv handling to be appropriate for Windows, and you'll have to implemented a Windows version of newosproc0.

You might also have to worry about how thread-local storage works in a DLL (I have no idea how this sort of thing works on windows)

@nadiasvertex The main thing is to make the function hostlink in cmd/link/internal/ld/lb.go do the right thing on Windows. On Darwin it invokes theC linker with -dynamiclib. On GNU/Linux it invokes the C linker with -Wl,-Bsymbolic -Wl,-z,relro -shared -Wl,-z,nodelete.

If you just want to build a DLL that does not contain any C code, you don't have to use external linker. I am sure you can modify Go linker to produce what you want. Go linker does just that when it creates windows executables. I don't see how creating of DLL would be different.

You will also have to deal with issues every windows DLL deals with. You must have set of mimimum functions required in DLL. You have to deal with your DLL exported functions called on different threads. You have to deal with exceptions.

You might also have to worry about how thread-local storage works in a DLL (I have no idea how this sort of thing works on windows)

What is wrong with the way thread-local storage works in Go windows executables now?

Alex

Let me be clear, I assume that go has already dealt with most of these
problems. I can certainly provide some glue for existing services. However,
if there is a need to write totally new runtime support I will need a lot
more direction.

On windows there were certain conventions for dll entry points. However,
those are generally C library artifacts. If go has particular needs I might
be able to satisfy those, given some pointers.

My personal need is to take go code, expose some of it via a C ABI, and
link an executable written in another language with it. The code needs to
work on Windows, Linux, and Mac. Android, iOS, and Windows Mobile are a
plus, but not urgently pending. Go satisfies most of these wonderfully. I
am interested in any solution that helps me accomplish this goal. I would
prefer a robust, integrated solution. However, if it is an unreasonably
large task for a new contributor then I would be happy to know about
workarounds.

On Mon, Dec 7, 2015, 7:27 PM Alex Brainman notifications@github.com wrote:

@nadiasvertex https://github.com/nadiasvertex The main thing is to make
the function hostlink in cmd/link/internal/ld/lb.go do the right thing on
Windows. On Darwin it invokes theC linker with -dynamiclib. On GNU/Linux it
invokes the C linker with -Wl,-Bsymbolic -Wl,-z,relro -shared
-Wl,-z,nodelete.

If you just want to build a DLL that does not contain any C code, you
don't have to use external linker. I am sure you can modify Go linker to
produce what you want. Go linker does just that when it creates windows
executables. I don't see how creating of DLL would be different.

You will also have to deal with issues every windows DLL deals with. You
must have set of mimimum functions required in DLL. You have to deal with
your DLL exported functions called on different threads. You have to deal
with exceptions.

You might also have to worry about how thread-local storage works in a DLL
(I have no idea how this sort of thing works on windows)

What is wrong with the way thread-local storage works in Go windows
executables now?

Alex

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

If you just want to build a DLL that does not contain any C code, you don't have to use external linker. I am sure you can modify Go linker to produce what you want. Go linker does just that when it creates windows executables. I don't see how creating of DLL would be different.

It's unusual to want to build a shared library/DLL if you don't have a C toolchain available. On Unix we decided to simply rely on that, rather than spend the time to teach the Go linker how to generate a shared library. On Windows, in which DLLs are more different from executables than they are on ELF, I would suggest following the same strategy. Since in the general case we must use external linking when generating a shared library, I don't think it's so bad to always require it.

On windows there were certain conventions for dll entry points. However,
those are generally C library artifacts. ...

It is not true. There are variety of non C compilers on Windows that will allow you to build a DLL.

My personal need is to take go code, expose some of it via a C ABI, and
link an executable written in another language with it.

You don't have to use DLLs for that. You can also include your Go code as part of your final executable. But then you need to be specific about the tools you use to build that executable. Is that going to be gcc? If yes, then what Ian suggests is your path. I do not know much about gcc, so I am not familiar with what is required.

You can also try and create DLL using gcc. Again, that is path that Ian suggested.

If you don't want to rely on gcc to build your programs, then you would have to build windows DLL as part of Go linkers. The code lives in $GOROOT/src/cmd/link/internal/ld/pe.go. Current code produces Windows PE executable (among other things). You can modify it to output Windows DLL (with whatever DLL requires). I am familiar with pe.go, but I have never built a DLL from scratch. But happy to help.

You should, probebly, try gcc approach first, because it has been implemented on some non-Windows OSes already. So, perhaps, it will be easy enough.

It's unusual to want to build a shared library/DLL if you don't have a C toolchain available. ...

Perhaps I misunderstand you, but I disagree. I don't see how building Windows DLL is different from building Windows executable. Surely we require gcc for cgo, but other than that.

On Unix we decided to simply rely on that, rather than spend the time to teach the Go linker how to generate a shared library.

Fair enough.

On Windows, in which DLLs are more different from executables than they are on ELF, I would suggest following the same strategy. Since in the general case we must use external linking when generating a shared library, I don't think it's so bad to always require it.

There are advantages of not requiring gcc on Windows. Go just works out of the box. When things break, you have all source code with you; and source code is Go. You can build Go Windows executable on any other OS - you can use Plan9 computer to build Go Windows executable.

Alex

@alexbrainman This issue is specifically about -buildmode=c-shared. The only reason to use -buildmode=c-shared is to build a DLL that can be linked into a program written in C. My thinking is that people doing that are probably also writing a program in C, and therefore have a C compiler. But I'm obviously not a Windows developer, so I may be wrong.

This issue is specifically about -buildmode=c-shared. The only reason to use -buildmode=c-shared is to build a DLL that can be linked into a program written in C. My thinking is that people doing that are probably also writing a program in C, and therefore have a C compiler. But I'm obviously not a Windows developer, so I may be wrong.

Fair enough. Similar I am not familiar with what -buildmode provides. What -buildmode flag should I use to build Windows DLL? DLL that can be called from any Windows executable or another DLL. These others (executables and DLLs) can be written in C, but don't have to be - they can be written in Go. We (Go executables we build) use system DLLs (produced by Microsoft) all the time. Do you see Go provide way to build DLLs just like these?

Alex

The intent is to write a plugin package that can be used to open Go shared libraries built with -buildmode=plugin. But this has not been implemented (see https://golang.org/s/execmodes for this and more about -buildmode).

On Windows, it may already work to use -buildmode=c-shared and open the DLL from a Go program. The disadvantage would be that you can only use functions with a C style interface, and you would have two different Go heaps and garbage collectors--one in the main program and one in the DLL. That is, -buildmode=c-shared is intended to give you a complete DLL that can be opened by a program written in any language, so it includes a complete copy of the Go runtime.

Thank you for explaining, Ian.

Alex

You might also have to worry about how thread-local storage works in a DLL (I have no idea how this sort of thing works on windows)

What is wrong with the way thread-local storage works in Go windows executables now?

Nothing, but it works by assuming g lives at a fixed offset from $fs, and when you are in a dynamic library that's going to be loaded into another process, you can't assume a fixed offset because something in that process or another dynamic library might already be using that offset. Or at least, that's the sort of problem you get on an ELF system -- like I said, I don't know how windows works here. But I suspect you'll need to change something in the area.

Yes. We would have to find different way to find TLS slot.

Alex

To provide some clarity on my motivation and goals:

I want to build a .dll because I don't know what code will eventually consume the pieces I am responsible for. In some cases a static library is enough, but in other cases it is not. For example, JNI and C#'s PInvoke require a .dll file. If it turns out that making a go .dll via -buildmode=c-shared is a larger project than I can take on, I hope to fall back to creating a static library via -buildmode=c-archive and then write some C functions that call the Go code, and are themselves DLL exports.

I understand that cgo already lets me register callbacks, and it certainly allows me to call into C code which may do just about anything. Consequently, I would imagine that the TLS problem has already been solved. I understand that a .dll adds some additional wrinkles to this situation, but I have to imagine that that is limited to the setup code.

With respect to @mwhudson, I don't understand what problem you are describing. If you are saying that the $fs segment register is used as a base, I'm not sure why you think what some other process is doing matters. The entire register set contents are isolated per process. The code itself lives where it lives, and is updated through the GOT and PLT tables at dll initialization. I confess that it has been a long time since I dealt with any of this in detail so I certainly may be missing something important here.

However, considering that this all works for non-Windows platforms, and considering that the Windows support for generating native go code is very good, I have to imagine that the vast majority of these issues are known and have been solved. I am very interested in specific guidance, and in known limitations of the go toolchain. I'm not terribly interested in generic 'thar be dragons" commentary because if this was really trivial it would be done already. :-)

@amiracam that is odd, since I see the patches in the commit list for that branch. However, I will look into it. Thanks for pointing this out!

With respect to the generated .h file, my patch doesn't have anything to do with that. They are compiler and linker changes only. I didn't touch the C FFI layer. I wonder if you are using a supported C compiler.

@nadiasvertex , yes agreed, i had checked out the patches from within the GIT page and they do indeed show up there, then I took a shot at looking at the zip.

I'm on Win 10 64 bit ,I believe its using GCC and indeed I use GCC to compile the project

@nadiasvertex , so I can generate a .h and .dll and can import that into a c project and do a build which will generate an executable without any errors, however when I try to run the executable it runs without error but does nothing ie. it should have print to console, I can tomorrow morning submit my very trivial experiment, BTW, I'm using the TDM-GCC distribution

@nadiasvertex
GO code:

package main

import "fmt"
import "C"

func main(){}
//export HelloWorld
func HelloWorld() {
fmt.Println("Hello")
}

which via
go build -buildmode=c-shared -o hello.dll hello.go

generates a hello.dll as well as hello.h
btw, also tried naming the output hello.so

C code (driver.c) :

#include <stdio.h>
#include "hello.h"

int main(){
setvbuf(stderr, NULL, _IONBF, 0);
FILE *fn = fopen64("hello.txt", "w");
fprintf(fn, "Hello there ");
fclose(fn);
printf("Hello \n");
HelloWorld();
return 0;
}

for which i use
gcc -o hello.exe driver.c hello.so

this will generate hello.exe

which when executed will do absolutely nothing

if I comment out the exported HelloWorld function and as well the include for the hello.h and compile , I do get a working exe but of course thats just a sanity check. Something about linking the shared object / dll generates a silent non-working executable.

I'm new to C and well pretty new to GO as well, how can I go about debugging this ?

thanks

@amiracam Have you tried this under Linux or macOS? If so, does it work there?

yes sir, works fine on MacOS Sierra , have not yet setup GO under Ubuntu but if it works on the Mac pretty sure it would work on Linux, ultimately we want to be cross platform Windows / Linux , I'll start testing there as well

@amiracam okay. That is useful to know. I will look into it.

@nadiasvertex
perhaps something else that is useful is that we are having success using buildmode=c-archive , basically following the instructions here:
https://stackoverflow.com/questions/40573401/building-a-dll-with-go-1-7

but using a clean GO 1.8.3 distribution

on Win 10

we can generate a working executable

@nadiasvertex hi, do you now have a 1.9 rebase? thanks

@ianlancetaylor

I am trying to make c-shared work on windows,. There is a codegenArg variable in cmd/go/internal/work/build.go:BuildModeInit - it controls the linker's -installsuffix argument. The codegenArg is blank for darwin, but it is set to "-shared" for other OSes. What should I set it for windows? It seems to work either way. Thank you.

Alex

Change https://golang.org/cl/68410 mentions this issue: misc/cgo/testcshared: skip all but TestExportedSymbols on windows

@alexbrainman The codegenArg is passed to the compiler and assembler, and also sets the install suffix. The main purpose of the argument is to change the code generation. If you don't need to pass any special argument to the compiler on Windows--if the normal code works fine in a shared library--then don't set codegenArg. The bit about installsuffix is to separate the packages compiled with -shared from the packages compiled in the normal way. Hope that makes sense.

Hope that makes sense.

It does make sense. Thank you for explaining. That is how I read the code.

It just both codegenArg="" and codegenArg="-shared" worked for compiler and assembler, and I need to pick one value. And the value I pick will affect where built package will be stored by the linker. For example misc/cgo/testcshared/cshared_test.go has some code https://github.com/golang/go/blob/d153df8e4b5874692f4948e9c8e10720446058e3/misc/cgo/testcshared/cshared_test.go#L43:L54 that needs to change to support my change. I wonder who else will be affected? What happens if one day we need to change codegenArg value? Darwin is already in that boat. So I will go with codegenArg="" for the moment as per your suggestion.

Alex

Change https://golang.org/cl/68770 mentions this issue: misc/cgo/testcshared: delete testp0.exe not testp0 file

Change https://golang.org/cl/69091 mentions this issue: cmd/dist, cmd/link, cmd/go: make c-shared work on windows

Change https://golang.org/cl/69090 mentions this issue: misc/cgo/testcshared: use correct install directory on windows