That was it. It's actually
export LD_LIBRARY_PATH=${PWD}
On Thursday, April 30, 2020 at 1:05:58 AM UTC-6, Miki Tebeka wrote:
>
> 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/2722055f-2a07-4605-bb01-3f544f362b2e%40googlegroups.com.
