Thank you for your reply, I was under impression that prototype definitions come from C header files, and since the compilation phase completes with success, cgo finds all necessary function definitions. My problem is at the linking phase when the linker by some reason tries to resolve ALL functions from the shared library, even those which are not directly used/called in CGO code. This causes CGO_LDFLAGS variable to be enormously long as I have to add around 3k of libraries. Using LDFLAGS environment variable is no better, as after adding all libraries to make LD happy, it exceeds the size limit and pretty much kills bash.
I am starting to get this: ``` dev-1:/user/sbezverk/go_connect > ls -bash: /bin/ls: Argument list too long ``` For every internal bash command I try to execute. I was wondering if there is a keyword forcing the linker not to try to resolve everything when building a binary, but to let the dynamic linker to deal with it at the execution time. Thank you Serguei On 26/09/23, 06:20, "Ian Lance Taylor" <i...@golang.org <mailto:i...@golang.org>> wrote: On Sat, Sep 23, 2023 at 6:38 AM sbezverk <sbezv...@gmail.com <mailto:sbezv...@gmail.com>> wrote: > > Since I could not find the answer in the cgo documentation, I would really > appreciate if somebody could help me to understand why when I build cgo code > with calls to the shared library, the linker tries to find the shared library > even though it is instructed to build dynamic binary and not static. > > > > I have C built shared library, I have no control how it gets built, I only > have lib_blahblah_x64_86.so . There are 2 external functions > bind_wrapper/unbind_wrapper in that library which I call from cgo. > > > > Here is the command line I use to compile: > > > > CC=/bin/tools/llvm11/llvm-11.0-p25/bin/clang-11 go build -o go_connect > -linkshared -ldflags "-linkmode external -extldflags -dynamic" go_connect.go > > > > The compilation succeeds, but the linker is complaining: > > > > /tmp/go-link-2323626149/000001.o: In function > `_cgo_df3b8c92b86e_Cfunc_bind_wrapper': > > /tmp/go-build/cgo-gcc-prolog:68: undefined reference to `bind_wrapper' > > /tmp/go-link-2323626149/000001.o: In function > `_cgo_df3b8c92b86e_Cfunc_unbind_wrapper': > > /tmp/go-build/cgo-gcc-prolog:87: undefined reference to `unbind_wrapper' > > clang-11: error: linker command failed with exit code 1 (use -v to see > invocation) > > > > > > My expectation was that the linker will not check external references to > these functions while building the binary, and only when the binary is > executed, the dynamic linker will attempt to resolve them. I am suspecting I > got something wrong, appreciate if somebody could provide some suggestions. Usually people use #cgo LDFLAGS lines to tell cgo where to find the shared library you need to link against. You can also use the LDFLAGS environment variable to do this. The basic issue is that cgo needs to see the definition of the C function so that it knows what its arguments are, including their types. It needs the information in order to generate a call to the function. Ian -- 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/333CDA20-E50A-4896-B8F1-D1EE02450028%40gmail.com.
