How to force cgo to use C++ compiler (g++) instead of gcc ?

[Elemer Pixard]

I am developing a binding to a C++ library
using a wrapper module (using extern "C" directive).
The C++ library files are in a subdirectory of the package.

If I create a file in the package directory such as:

lib.cpp
--------------
#include "cpplib/file.cpp"
#include "cpplib/wrapper.cpp"
--------------

It works, but if I create a Go file instead such as:

lib.go
--------------
package lib

// #include "cpplib/file.cpp"
// #include "cpplib/wrapper.cpp"
import "C"
...
--------------

This doesn't compile because cgo uses gcc instead of g++.
I would prefer this second way because I need to
configure the build using tags.
Is there a way to solve this ?

Regards.

[Jan Mercl]

On Sun, Oct 31, 2021 at 6:17 PM Elemer Pixard <elp...@gmail.com> wrote:

> Is there a way to solve this ?

Some hopefully related info can be found here:
http://www.swig.org/Doc3.0/Go.html

[Andy Polyakov]

lib.go
--------------
package lib

//  #cgo CFLAGS: -x c++

// #include "cpplib/file.cpp"
// #include "cpplib/wrapper.cpp"
import "C"

Formally, the remaining question is if C compilers on all of your target platforms support -x option. In the worst case, if some does not, you should be able to set CC environment variable to call a script that will call C++ compiler behind the curtains.

[Andy Polyakov]

Hmm, previous suggestion to use '#cgo CFLAGS: -x c++' doesn't seem to work all the way. [I've only tested class declarations at the time.] Trouble is that '-x c++' is passed even when compiling the glue code, so that even glue symbols get decorated, which doesn't fly with linker at the end. I suppose the only way is to collect extern "C" declarations in a header file, include it in the 'import "C"' section, compile lib.cpp separately and link with it, e.g. with #cgo LDFLAGS: lib.o. Or make it a library and set LDFLAGS to '-L. -lname'...

[Ian Lance Taylor]

There is no way to get this to work using #include "cpplib/file.cpp"
in the cgo comment.

I don't understand why the lib.cpp approach doesn't work, though. You
say that it needs tags, but what tags does it need?

Ian

[Elemer Pixard]

The objective is to allow the end-user to
configure the library using Go build tags.
For example:

lib.go
---------------------------
package lib

#include "cpplib/common.cpp"
#include "cpplib/wrapper.cpp"
import "C"
---------------------------

backend1.go
---------------------------
// +build backend1

package lib

#include "cpplib/backend1.cpp"
import "C"
---------------------------

backend2.go
---------------------------
// +build backend2

package lib

#include "cpplib/backend2.cpp"
import "C"
---------------------------

So the user  build the library for different backends:
>go install -tags backend1
or
>go install -tags backend2

[Ian Lance Taylor]

Why not just put a build tag in your lib.cpp files?

Ian

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ba041b6b-764c-4b30-90cb-c2cc28479935n%40googlegroups.com.

[Elemer Pixard]

I didn't even tried because I assumed that build tags were processed only  for ".go" files.

But it worked !!!

Thanks !