Shared Library Mysteriously Doesn't Get Linked to Application

Shared library mysteriously doesn't get linked to application

tl;dr version: Add -Wl,--no-as-needed to the link command.

After a series of experimentation and conversations with the OP, I've figured out what's going on.

In the latest version of Ubuntu, ld uses --as-needed by default. What that does is to remove references to libraries that are not explicitly required.

The way Hoard works is as an LD_PRELOAD library. i.e., you are not supposed to need to use functions in libhoard.so directly. Of course, you could link in libhoard directly if you wanted to...unless --as-needed is used, of course.

After discovering this, the solution is simple. Just add -Wl,--no-as-needed to the gcc linking command.

Error while loading shared libraries: libcudart.so

Okay, finally I figured it out and solved the problem. In the end, your comments lead me to the solution. I simply forgot to specify the CUDA library explicitly, which I didn't know I have to do.
I changed

target_link_libraries( Server ${OpenCV_LIBS} ${Boost_LIBRARIES} Spinnaker )

to

target_link_libraries( Server ${OpenCV_LIBS} ${Boost_LIBRARIES} Spinnaker ${CUDA_LIBRARIES} )

It is now, as noted in the comments, by default linked statically.

how to block a signal before shared library creates a thread?

Doesn't seem to be possible -- shared library should block all signals in created threads if it really needs to create a thread so early.

Using shared libraries vs a single executable

I'd say that splitting code into shared libraries to improve without having any immediate goal in mind is a sign of a buzzwords-infested development environment. It is better to write code that can easily be split at some point.

But why would you need to wrap C++ classes into C-function interfaces, except for, maybe, for object creation?

Also, splitting into shared libraries here sounds like an interpreted language mindset. In compiled languages you try not to postpone till runtime what you can do at compile-time. Unnecessary dynamic linking is exactly the case.

ld: library not found for -lPods only when run in real device

Assigning the target in Podfile has resolved the problem.

target :TechMoviePlus do
  pod "AFNetworking", "~> 2.0"
  pod "LBGIFImage"
end

Statically linked libraries and JNI?

You are correct: the JVM can load dlls (you normally have some startup code in the Java source code that contains native functions to load them). It cannot load libs.

So you will need to create a dll that statically links to the libs.

The normal way to do this is to run the program javah which will generate the stubs for the dll functions that you need to implement.

gcc linking with static libraries

sqrt (2.0);

Modern GCC is well capable to determine that you are trying to find square root of a constant and thus it is able to calculate that in compile time. Your object code does not contain an actual call to sqrt.

If you use a variable which is input via scanf at run then it won't link without libm.

int main() {
    double x;

    scanf("%lf", &x);
    printf("%lf\n", sqrt(x));

    return 0;
}

Without libm gcc 4.8.4 on Ubuntu 14.04 this results:

/tmp/ccVO2fRY.o: In function `main':
sqrt.c:(.text+0x2c): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status

But if I put a constant instead of x like your example then it links fine without libm.

P.S: I don't know the exact version since when GCC is able to do this. Hopefully someone else can point to that.

---

Related Topics