Can you show us a small self-contained example that demonstrates the problem?

Can you show us a small self-contained example that demonstrates the problem?

I wish I could direct you to the library in question for testing, but unless you are a Russian national, residing inside the borders, me doing so will bring me to the prosecutor office faster, than I'd be able to type the F-word, due to the nature of the library in correspondence with export legislation.

So, let's try the code samples and package structure.

Let's say the package is called wrapper and it has internal folder cwrap for wrapper shared library, which was build with -c -fPIC and linked with the original library as -shared.

cwrap.h contains inclusions to support the original library call;

extern.h:

extern void wrappedCall(void *);

cwrap.c contains implementation of the wrappedCall function calling OriginalCloseObjectFunction,
accepting the pointer to some struct;

inside the parent wrapper package folder there are two files:

wrapper.go:

// +build darwin,cgo dragonfly,cgo freebsd,cgo linux,cgo netbsd,cgo openbsd,cgo

package wrapper

// #cgo LDFLAGS: -L${SRCDIR}/cwrap -lcwrap
import "C"

and call.go:

// +build darwin,cgo dragonfly,cgo freebsd,cgo linux,cgo netbsd,cgo openbsd,cgo

package wrapper

import "unsafe"

// #include "cwrap/extern.h"
import "C"

// CallClose wraps calling C.OriginalCloseObjectFunction; always returns nil.
func CallClose(ptr unsafe.Pointer) error {
    C.wrappedCall(ptr)
    return nil
}

Now, calling go vet or go build inside the wrapper folder results in:

wrapper/cwrap/libcwrap.so: undefined reference to `OriginalCloseObjectFunction`
collect2: error: ld returned 1 exit status

UPD: On the original developer library support forum there's a mention for the same issue which was solved by placing -L and -l flags data after the .o, just as I supposed in the original statement; and the person who posted the problem there was also using Ubuntu, may be it's an Ubuntu thing I'm starting to think...

So, the question is: how can I redefine the linker arguments for building the code?

You don't need to show us the original code. Just show us a small self-contained example that demonstrates the problem. You described it but it will be easier to see it in code.

From your description I don't understand why there is a problem. But since there is a problem, I would suggest changing LDFLAGS from -lcwrap to simply cwrap.o. If it really has to be a library, then perhaps -Wl,--push-state -Wl,--whole-archive -lcwrap -Wl,--pop-state.

You don't need to show us the original code. Just show us a small self-contained example that demonstrates the problem. You described it but it will be easier to see it in code.

From your description I don't understand why there is a problem. But since there is a problem, I would suggest changing LDFLAGS from -lcwrap to simply cwrap.o. If it really has to be a library, then perhaps -Wl,--push-state -Wl,--whole-archive -lcwrap -Wl,--pop-state.

I've tried both approaches: compiled library with mentioned flags and switched to cwrap.o solution, and, yet, anyway it issues the undefined reference error on go build. And in my previous answer I have almost the exact contents of the package in question, I just replaced names with something else. CallClose looks exactly the way it looks in the package, it's just names that differ, the contents of the cwrap.c looks like:

void wrappedCall(void * ptr) {
    OriginalCloseObjectFunction((CASTED_POINTER_TYPE)(ptr));
}

Just a single line wrapper.

For some unknown reason in the whole library, I'm wrapping, the only symbol causing this issue is that one, and, yet, since it is really a memory freer, a closer 5 different objects rely on it to be called. I can't avoid it. I tried to create a separate go package dedicated to that symbol; I tried wrapping the symbol in a library, both shared and static, I've tried your previous suggestions, all of them — once engaged with cgo — result in an undefined reference gcc linker error, whilst if I wrap the original library in a static or shared one, I have no problems in building it with the same gcc linker.

I've looked up go help build and called go build -x to find out the everything looks normal up until the very end, where all generated in previous steps .o files are getting linked, the command line looks perfect in terms of my previous ideas, the .o files are exactly before any -l mentioned data.

I understand that this is some kind of undefined incompatibility between the shared library, I'm wrapping, and cgo, and yet I have no idea how to figure out what exactly is going on.

That OriginalCloseObjectFunction symbol is just being constantly missed from the linking, though nm finds it perfectly fine anyway.

I've tried to change -compiler option to =gccgo, and it resulted in cmd/go: gccgo: exec: "gccgo": executable file not found in $PATH, if called from the some subpackage of subpackge of subpackage, and in single line output on -x option: WORK=/tmp/go-build527216309 if called from src/some-package/.

Issue is closed.
I'm once again a blind idiot.
There's nothing to do with the go, but with the idiot trying to use it.
My apologies.
nm listed not the OriginalCloseObjectFunction, but rather a OriginulCloseObjectFunction;
I'll be addressing my optometrist and the library being wrapped developer.
Once again, I'm sorry.

No worries, thanks for following up.

No worries, thanks for following up.

You, I have the same problem. Can you tell me how to solve it?

@denisvolin I appreciated the level of detail. Can you elaborate on what the solution was? I too have a similar problem.