Access Golang module from Visual C++ - go

Is there a way of doing this?
Develop a library L1 written in Golang. L1 exports functions for C language.
Build L1 and generate .lib file for Visual C++.
Use L1 from Visual C++ code by calling C functions in L1.

I've never tried, and I'm using linux, but here is what I know:
According to the golang documentation you can compile go code into shared library (see go help buildmode also).
To be able to call go function from c code, go function shall be exported.
In order to compile your go code into a shared library, you need to get the go standard library into a shared one too:
go install -buildmode=shared std
This will compile all the go standard code into libstd.so (on linux, the name might change on windows).
And finally, you can use the following command to get your shared library:
go install -buildmode=shared -linkshared [packages]
The standard shared library can be found in:
GOROOT/pkg/GOOS_GOARCH_dylink/
and your shared library under:
GOPATH/pkg/GOOS_GOARCH_dylink/
That is for the go part.
Now, if you want to call this code from a C++ project, you'll need to create the C library that wraps the go library. You can use some tool for that (I've heard about SWIG, but never tried).
EDIT: You can do something similar with static go library, but since you did not specify the library type and you will use it from C++ code, I suppose you need a shared library.

Related

How to use Go -buildmode=archive

Using -buildmode=archive produces mylib.a. I'm not fully understanding the steps required to then use this library in another Go program.
I've tried instead generating -buildmode=c-archive which produces a header file and archive, but the headerfile is not designed to be imported using cgo (there is conflicts with imported types).
Research online has yielded the conclusion that -buildmode=c-archive is specifically not designed for cgo use for this reason.
My query is what is -buildmode=archive actually used for if it cannot be included?
I'm not fully understanding the steps required to then use this library in another Go program.
It can be tricky. Need to look into each compiler toolchain for linking them correctly, i.e. gcc/clang etc. and find how, and if it's even possible to link them and use them.
What is -buildmode=archive actually used for if it cannot be included?
From the docs: https://pkg.go.dev/cmd/go
-buildmode=archive
Build the listed non-main packages into .a files. Packages named
main are ignored.
That's what it does, what you do with it, it's up to you, there's tons of information online, for example: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Go code building linker error. Can I link manually?

I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.

Go target language

What is the Go language compiled to? Nobody seems to want to write it anywhere on the net. I am searching for the target language. I am thinking it's probably assembly, C, or relocatable machine code?
The reference implementation compiles Go to native machine code. The code is generated to be not relocateable.
The language has been designed to allow other target platforms as well. For instance, there are implementations that compile Go code into Javascript and PHP.
It is not possible to use Go code in a shared library.

Referencing Source Files of Shared Libraries in Valgrind

We have a software project which has the primary purpose of providing a library and API. We also provide example programs and utilities that use this library.
So, let's say that I have built and installed our library. When I run valgrind on one of the example / utility programs, I obviously see references to functions in the library. The issue is that it doesn't provide line numbers, and I would like it to.
Is there a way to tell Valgrind to reference source files that aren't obviously part of an executable, but are part of the source code for a library that is linked-in to the executable?
Thanks!
Make sure that you are compiling shared library with -g to add debug information. This should be enough for Valgrind to reference source files. See http://valgrind.org/docs/manual/faq.html#faq.unhelpful for more information.

How to link with static libraries when building an R package

I'm creating a package that is going to be used by R (the statistical program), I'm not an expert using this application but I have managed to create a very simple package, using the following logic, I have some classes in C++, as the code has to be compiled using the R compiler and it only allows C code, I have a wrapper C code that call the C++ methods, and later I have an R script that call the methods exposed by the C code, so basically is a communication like R <-> C<->C++.
The full tutorial that I used to create this package is found here, I add it as a reference.
Now my problem is that I need to add some functionality to the package that I already created, what I need to do is to add code for late binding to a COM object which is another product that I created and that is registered using regasm tool.
This is the c++ code that I'm using to try to late bind to the COM object, I'm trying to use IDispatch to do so:
{
...
CLSID clsid;
HRESULT hr = CLSIDFromProgID((WCHAR*)"My Com object ProgId", &clsid);
if(FAILED(hr))
return;
...
}
I didn't paste the whole code because only with these lines the compiler is giving me troubles already, the command I use to compile is
R CMD SHLIB Cclass.cc C++class.cc
Where "Cclass.cc" has the C code that call the c++ methods and "C++class.cc" is actually the C++ code.
When I compile these classes the compiler says "undefined reference to `CLSIDFromProgID#8'collect2: ld returned 1 exit status"
I"m sure I have added all the header files that I need, that's why I believe my problem is that I'm not including ole32.lib and oleaut32.lib which are static libraries.
So, my question is, how can I include this libraries in order to be able to use the methods for late binding, like CLSIDFromProgID(...) or QueryInterface(...). Also if anyone believes that my problem is not linking this libraries, but something else, it would be great if can point me to which my problem may be.
Also have in mind that I need to link with those statics libraries in a way that they can be compiled without problem by the R compiler, which if I'm not wrong is a merely c compiler.
I've not tried doing this with C/C++ but rather with Fortran. I had a similar problem in that some standard IO libraries weren't being included in the library I was created. In the end I just included them all and compiled using the Fortran compiler. I didn't use any of the R compiler utilities, just compiled as if I were compiling a static Fortran library normally for use with anything else. This worked fine.
A debug path might be to compile as a static library using gcc (or whatever you're using) then try to include and call that static library from another C program, then if that works try with R.
Hope this is helpful, writing these R packages is pretty hard unless you're using vanilla C or Fortran as far as I can tell.

Resources