TurboActivate on FreeBSD, static vs shared libAnswered

Scenario:
- FreeBSD 13.1, 64-bit
- Clang++ 14.0.5 (base compiler of FreeBSD)
- TurboActivate 4.4.4.0
- C++

While testing LimeLM on FreeBSD we noticed a difference in behavior between that static and the dynamic/shared libraries provided. Our simple test program (largely based on the provided example) seems to work as intended while using TurboActivate as a shared library. Once we switched over to the static library, TA_CheckAndSavePKey() still succeeds but TA_Activate() consistently returns TA_E_INET_TLS.
While we studied the documentation specifically provided for that error (such as network issues), we ruled out most of these problems as our particular test setup shouldn't be affected by any MITM issues. Furthermore the exact same test application works flawlessly when linking the shared library instead.

Is there anything obvious that we're missing that needs to happen when using the static library version of TurboActivate? Any compile time definitions or similar that we're missing?

Answer

It's hard to use static libraries correctly. There are a lot of ways things can explode. So, if you run into any problem at all with a static library our advice is always to use the dynamic library.

From the FAQ: Don't use the static library, only use the dynamic library!

Thank you for your reply.

We put a lot of effort into our application ensuring that everything non-base related could be linked statically. Therefore, this is a bit of an itch :D

Are you able to confirm that the static library of TurboActivate 4.4.4.0 works as expected on your testing environments with FreeBSD 13.1 64-bit?

In the meantime we triple checked that we're using the same compiler defines, flags & linker flags as the provided example Makefile.
Right now we're inspecting the shared library with ldd and readelf in hopes of figuring out whether we have to explicitly link some dependency of TurboActivate as this wouldn't be recorded anywhere in the static library (compared to the shared one).
Would you be able to provide details regarding external dependencies of the TurboActivate static library as well as the compiler (and possibly environment) used to produce the static library?
 

, edited

All of our tests with the static libraries work fine. But again, the static libraries aren't conflicting with other libraries.

Would you be able to provide details regarding external dependencies of the TurboActivate static library as well as the compiler (and possibly environment) used to produce the static library?

The latest at the time we built them. Every release will have a slightly different compiler. You can clean some of these things from the standard compiler tools.

But honestly, it's not worth the effort to try to “build the perfect environment”. Just use the dynamic libraries. They work as designed. They're self-contained and are robust. And that way you don't have to try to match our ever-changing build-environments.

Reply
Discard post