Testing with CGO Libraries

[Brian Ketelsen]

I have an application that uses the gozmq libraries from Alec Thomas. That library uses CGO, and requires libzmq.so to be installed. The application that I've written works beautifully, and I'm quite enjoying the 0mq protocol for RPC work. My problem is that when I have test files, I can't run the tests, no matter what I try. The gotest command always fails with the error "error while loading shared libraries: libzmq.so.1: cannot open shared object file: No such file or directory"

To make this work, I've been manually exporting "LD_LIBRARY_PATH=/usr/local/lib" before running gotest.

Here are my questions:

Is this intended behavior? Will a Go package linked against a shared library require any OTHER application/package that imports it to also inherit the LDIMPORTS requirements with it?

I searched the gotest documentation and couldn't find any way to pass linking details through. Is this a bug?

I emailed about this a day or two ago, before I fully understood what was going on. Now that I have a better grasp of the situation, I believe it to be a bug, but my lack of gcc/linking/c development experience is making this harder for me to report. It could be that this is a normal problem with shared libraries and the solution is to add /usr/local/lib to some sort of global LD_LIBRARY_PATH setting somewhere -- but that doesn't sound very Unix-y.

I'm very open to suggestions! Thanks for helping me understand what's going on.

Brian

[Russ Cox]

I think the most common solution is to add /usr/local/lib
to your system's global library search path, or to install
the libraries somewhere that is on that path.
You would have the same problem with binaries not
finding the libraries if you had built them with C.
Or set $LD_LIBRARY_PATH, since that is what it's for.

That said, at one point I planned for cgo to record the
information about rpath the same way it records information
about which libraries need to be imported, so that the
#cgo ldflags would work. I don't remember if that was
a bad idea for some reason or just didn't happen.
In general it seems wrong for libraries to be hacking
up the rpath settings of a binary they are linked into.

Russ

[Ian Lance Taylor]

Russ Cox <r...@golang.org> writes:

> I think the most common solution is to add /usr/local/lib
> to your system's global library search path, or to install
> the libraries somewhere that is on that path.

On GNU/Linux, man ldconfig.

> You would have the same problem with binaries not
> finding the libraries if you had built them with C.

Yes.

Ian

[Brian Ketelsen]

Thank you both. I'm glad to see it's not just a cgo issue, but didn't have enough C development experience to understand that.

Brian