Go using dynamic library C + + library __c++

Recently need to do some work in the go with the dynamic C + + library, often encounter the situation can not find a dynamic library path, so take the time to do a special experiment to understand go.

I. Sample code directory structure (assuming the code root is/home/gdc/cgotest):----|bin:
----|PKG
----|SRC
--------|main
------------|main.go
--------|oidb
------------|hello
----------------|hello.go:
----------------|api.h
------------|lib
----------------|libapi.so

Second, the Code
Api.h File Contents:
#ifndef __api_h__
#define __api_h__
void Hello ();
#endif

Hello.go File Contents:
Package Hello
/*
#cgo Cflags:-i./include
#cgo ldflags:-L. /lib-lapi
#include "api.h"
*/
Import "C"

Func Hello () {
C.hello ();
}

Main.go File Contents:
Package Main
Import "Oidb/hello"
Func Main () {
Hello. Hello ();
}

Third, the premise

A. Add the code directory to the GOPATH environment variable. --export gopath= $GOPATH:/home/gdc/cgotest

B. Environment variable Ld_library_path value is null

Iv. Some small experiments on the use of dynamic + + libraries in CGO:

A. According to the directory organization and file contents as above, you can perform the go build Oidb/hello, or a go build oidb/hello anywhere.

Executing the Go Build oidb/hello This command may not react, but can tell you that the compilation passed.

Execute the Go build oidb/hello this command to create the OIDB/HELLO.A in the PKG/LINUX_AMD64 directory under the code root (if no one exists automatically).

OK, which means the package is ready for use by others. But can other people use it properly. Then do some main.go related experiments.

B. Unfortunately, at this point I try to execute go build main or go install main in many places, and will prompt me not to find the libapi.so dynamic library.

But interestingly, when I execute go build main or go install main in the Lib or Hello directory, it will succeed. Where the Execute go install main is generated in the bin subdirectory of the code root

A main executable file, go build main generates a main executable program in the current directory. And then when I try to execute this main executable file in the bin directory, I'm prompted to find

Not to libapi.so this dynamic library.

Then I try to copy the Lib directory to the bin directory and the Code root directory, and then execute the main executable in the bin subdirectory, or I'm prompted not to find the libapi.so dynamic library.

Finally, I come up with the ultimate big move, execute "Export Ld_library_path=/home/gdc/cgotest/lib" (at this time I moved the Lib directory to the Code root directory), and then I can

Run the main executable program.

Then I move the Lib directory to the bin directory and the SRC directory, and then separately use the Export command to add the new location of this Lib directory to the LD_LIBRARY_PATH environment variable, and then execute main, which can be performed correctly.

Summary: the compiler understanding of the main package:

When you compile or install the main package, go is in the current directory at this time. Then, if a relative directory is used in one of the packages referenced by it, it relies on a dynamic library. Then, from the current directory, according to that relative position to find the dynamic library. So the above in compiling or installing the main package, but only in the Lib or Hello directory successfully compiled, this is because go from the current directory, to its parent directory of the Lib subdirectory look for the libapi.so dynamic library, and then successfully found, thereby by compiling. In fact, you don't necessarily have to compile the main package in Lib or the Hello directory. Just make sure that there is a subdirectory lib under the parent directory that compiles the main package location, and that there is a libapi.so file in the Lib directory that can be compiled. For example, I put the Lib directory under the code root, then I go to the bin directory, and then I can successfully compile or install the main package.

Of course, if you use a dynamic library using the "-l" option to set the absolute directory instead of the relative directory, then compile or install the main package, there are not so many restrictions. You can compile or install in any location.
Main executable execution of the program understanding:
Whether you use the "-l" option in your code, the dynamic library location specified is a relative or absolute directory. To execute this main executable, add the directory of the dependent dynamic library to the environment variable Ld_library_path (or copy the dynamic library to the system default library search path. But the boss does not allow Ah, depressed).

C. Below, do some experiments on the direct compilation of main.go files.
This compilation is the same as compiling the main package--"-l" using a relative path, you must ensure that the location of the compilation in addition to the relative path can eventually find the dynamic library, "-L" use absolute path, you can compile at any location.


D. Finally, do some experiments about setting environment variables in go. Because the main program's execution needs to rely on the value of the LD_LIBRARY_PATH environment variable.
D1. The first method: Wei Lao says, is to write a shell script that executes the export statement in this script, adding the path of the dynamic library to the Ld_library_path. Then run the program again.
Ok. This method is passed.

D2. The second method: Set the value of the environment variable in go.

After the experiment, and then ask Wei Lao, feel it is impossible. Because when the program starts, the system automatically loads the libraries that the program relies on, and the Code for setting the environment variable in your program isn't running yet. Of course, the dynamic library is still not found.

One workaround: Manually load the dynamic library yourself.

Reference to the http://blog.csdn.net/joker0910/article/details/6103793 this article manual loading library, can be used normally.

F. Supplements (2014.07.21).
Forgot to do the go test hello this experiment. After the experiment, it was found that if the-l in the package uses a relative directory to locate the dynamic library, the following two points are required to successfully execute this command:
First, make sure that the location where you execute the command plus the directory you get from the relative directory needs to contain the dynamic libraries that you rely on. This is similar to compiling or installing the main package.
Second, you need to add the directory where the dependent dynamic libraries are located to the environment variable Ld_library_path. This is similar to the execution main.

The revised Hello.go file reads as follows:
Package Hello

/*
#cgo Ldflags:-LDL
#include <stdlib.h>
#include <dlfcn.h>
#include "api.h"


void Hello_c (char* lib_path) {
char* func_name= "Hello";
void* libc;
void (*hello_call) ();
if (libc = Dlopen (Lib_path,rtld_lazy))
{
Hello_call = Dlsym (libc, func_name);
(*hello_call) ();
Dlclose (LIBC);
}
}
*/
Import "C"
Import "unsafe"


var Extension_dir string = "/home/guess/.davengu_workdir/go_learning/cgo/use_shared_library/src/oidb/lib/"
var Oidb_api string = "libapi.so"


#cgo Ldflags:-l/home/guess/.davengu_workdir/go_learning/cgo/use_shared_library/src/oidb/lib-lapi
#cgo ldflags:-L. /lib-lapi


Func Hello () {
LIBPATHC: = c.cstring (EXTENSION_DIR+OIDB_API);
Defer C.free (unsafe. Pointer (LIBPATHC));
C.hello_c (LIBPATHC);

}

Reference articles:

1. "Linux, manual loading dynamic Library": http://blog.csdn.net/joker0910/article/details/6103793