3 ms·
By that criteria Go doesn't have any support for DLLs either at the core language level, it just happens to export some Win32 API functions (LoadLibrary, GetPro
by georgemcbay 13y ago
By that criteria Go doesn't have any support for DLLs either at the core language level, it just happens to export some Win32 API functions (LoadLibrary, GetProcAddress, etc) via goc (like cgo but specific to the Go bootstrapping build process) in the win32 version of the syscall package that allow you to do your own DLL late binding.
- 4ad 13y agoGoc is nothing like cgo. Goc is a simple preprocessor that allows writing C code with Go function declarations, and it will transform said code into C code compiled by 6c using some rules that are somewhat hard for people to do by hand and not screw up. For all practical purposes, goc is not required, people can write the C code by hand, it bears no effect on linking and on the ability to use code in external objects. Also, it's seldom used, most of the code is C code, not touched by goc. The Go linker does know how to link with external objects and use their symbols, and it does this without requiring the external object to be present at link time. It can do this, because the most basic relocations don't require any knowledge about the object. This was previously supported only on PE-COFF, as it was previously used by the Windows target, but now I have extended it to ELF too, and it's used on the Solaris target. In principle, it works on every other ELF platform too (Linux, *BSD). Note that in all of these cases ABI translation needs to be done, and the internal machinery in the runtime that does this is in motion, just like with cgo. There's no difference in the runtime performance envelope, the only difference is that it doesn't require a target toolchain, like cgo does.