IMO the #cgo directive is just building the executable, not for running it.
You can set the LD_LIBRARY_PATH environment variable before running the
exeutable
LD_LIBRARY_PATH=${PWD} ./app
On Thursday, April 30, 2020 at 7:19:36 AM UTC+3, Dean Schulze wrote:
>
> I'm following a simple example
> <https://www.thegoldfish.org/2019/04/using-c-libraries-from-go/> of using
> cgo to call a C library function from go. Executing the binary gives
>
> error while loading shared libraries: libperson.so: cannot open shared
> object file: No such file or director
>
>
> Here's the relevant part from the main.go file:
>
> /*
> #cgo LDFLAGS: -L. -lperson
> #include "person.h"
> */
> import "C"
>
>
> The file libperson.so is right in the same directory with main.go and
> person.h. I've also created a soft link libperson.so.0 -> libperson.so but
> that doesn't have any effect. I've tried this with go run and by go build
> to create a binary but both give the same error.
>
> Does cgo recognize the LDFLAGS: -L. symbol at all?
>
> What do I need to do to get a go binary to call a C function in a .so? I
> really don't want to put my .so in the /usr/lib directory just to get a
> static linked binary for something like this.
>
$ LD_LIBRARY_PATH=${PWD} ./app
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/c2e7899f-beb1-4946-af63-0846c8217301%40googlegroups.com.
