Static Turbo Activate 4 library on Windows - not work, or not compileSolved

Dear support,

I am trying to compile new TA 4 static library (VS 2010) into our application, but I have still the problem:

- either the activation is not working (activate/deactivate reports TA_E_INET error) - if we are using our libcurl_imp.lib - or our code with CURL library is not working or crashing - if we do not include our libcurl_imp.lib (but is used curllib.lib) - or application can't be compiled, because of curllib-MD.lib(escape.obj) : error LNK2005: _curl_free already defined in libcurl_imp.lib(libcurl.dll) or libpng.lib(png.obj) : error LNK2019: unresolved external symbol _inflateReset referenced in function _png_reset_zstream

We are using TurboActivate-MD.lib

Could you help us to solve this issue?

We have used TA 3.4.6 before without any of the mentioned problems.Changing only the library (and API code for TA) resulted into linking errors because of duplicates of curl or zlib functions

TA 4.x uses newer libraries. You have a couple of options:

1. Always use our libcurl build.

2. Use the dynamic version of TurboActivate.

3. Compile the static TurboActivate into a different module so you won't run into these conflicts.

Honestly, using our dynamic version of TA is the best option.

Could you, please, specify the version of libcurl?

Wouldn't be possible to decorate your libcurl function names, if you use different version? This could also solve the problem probably, and we all will not be limited to use the precise version of libcurl, if you change it in the future.

I found out the version of Curl is 7.50.3.

>> "Wouldn't be possible to decorate your libcurl function names, if you use different version? "

There's no easy way to do that (not that I know of). And we're not going to dedicate our development time to renaming third party functions. We'd rather spend our time and money and making our products better.

>> "we all will not be limited to use the precise version of libcurl, if you change it in the future."

I can guarantee you that we'll continue to use the latest versions of 3rd party libraries to get speed and security improvements. It's in everyone's best interest that we do that.

I am not happy with your status of "solved", because I am still not able to get work TA4 with our app.

1. Either our app is not working with your static libcurl (network timeout)2. Or TA is not able to activate/deactivate with our dynamic libcurl.

I have recompiled our library to use curl of 7.50.3, but the error is same "Resolving timed out after 30014 milliseconds."

Does anybody have same issue with an application using libcurl itself?

Don't use any version of the included libraries except our pre-built ones. If you swap them out with alternatives you will get unexpected behavior.

My advice: use our dynamic libraries. Or, put whatever code that's using your version of libcurl into it's own dynamic library.

>> "I have recompiled our library to use curl of 7.50.3, but the error is same "Resolving timed out after 30014 milliseconds.""

I'm not sure what you mean. You're saying when you use libcurl it's failing? That sounds like a bug in your code (trying to contact a slow site, setting the timeout too low, etc.). This doesn't sounds like a problem with TurboActivate at all.

I am saying, that if I use Your static libcurl 7.50.3, I am not able to use upload commands.

When I am using libcurl 7.50.3, compiled by myself and used without TurboActivate, than every application (x86, x64) is working without any problem.

I have tried to use only your libcurl, without linking to my dynamic libcurl, but the problem persists.Using the same code with TA 3.4.6 is working without any problem in compilation or usage.

We need to upgrade TA4 because of Windows 10 users, but we are not able to do it for two weeks now.This is really shame, that only replacing Your static libraries is not working for us...

Our libcurl version is only built with HTTP and HTTPS. And it's built with the system SSL libraries (Microsoft Secure Channel on Windows) rater than 3rd party SSL libs. So if you're depending on the library to ignore "self-signed" certificates, or if you're using a protocol other than HTTP or HTTPS, then your code will fail with our built libcurl instance.

I don't know what to say beyond what I've already said. There's a conflict between our static libraries and your static libraries. This isn't a bug in TurboActivate, it's just the nature of including multiple static libraries in an app with conflicting names.

The solutions are any of the following:

1. Use the dynamic version of TA. This is recommended because you eliminate any problem of conflicting static libs.

2. Use the dynamic version of your library. (Or move the logic to its own dynamic library).

3. Or, if you're determined to make everything a static library, despite the obvious problems with that, then you could always use our version of libcurl, enable debugging in your app, and dig into exactly why it isn't working.

1 or 2 are the best options and the fastest options. Option 3 is not recommended.