Can't link both TurboActivate and TurboFloat static libraries on WindowsAnswered

Interesting. Well look into this for the next bug fix version. Its not a priority right now (other releases coming first). In the meantime, on Windows use the dynamic libraries.

Hello, I'm having the same issue with 4.4.3.0 and Visual Studio 2019.

Any updates on this, anything I can do on my end?

Thanks

Thanks for the quick reply, but sorry to hear it isn't working. Anything I can do on this end to make it a priority, or work around it until it gets fixed?

The workaround is to use the dynamic libraries. The static libraries are often more trouble than they're worth. The only real benefit they offer is a slightly smaller end executable (a few kilobytes saved).

I can see what you mean.

In this case, my software is already a dynamic-library (plug-in). In order for the plug-in to find the TurboFloat.dll, I will need to ask my users to edit their PATH environment variable ahead of launching the application hosting the plug-in. They are artists, so it's a tall order.

So in terms of distribution, documentation and presentation, the statically built TurboActivate has worked wonders so far and it would be wonderful if I could manage to squeeze TurboFloat in there as well. If it's a question of cost, I'd be happy to discuss it further.

You could just find the DLL (relative to your dll) and load it using LoadLibrary: https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryw

Thanks, that seems to do the trick.

Now the only remainder is presentation and distribution, from 1 file to 2. I'll be keeping an eye on this issue and cross my fingers that one day it can be resolved.

 

I'm back with another problem and a reminder of why all of my libraries are statically compiled; my software is a plug-in amongst many plug-ins, some of which are also using TurboFloat.dll (which is unsurprisingly popular!).

It's unclear what version they use, but it is unlikely the same as I do and with that I expect one or the other to conflict.

Is there a possible workaround for this?

You can name the TurboFloat.dll anything (for example “MyApp.TF.dll”) and then load it using the LoadLibrary function.

Thanks for getting back.

I'm a bit confused, probably because I don't understand dynamic libraries that well. In order to build, I need to link with `TurboFloat.lib`? From what I gather, that's the library that currently loads the dynamic library, and from what I gather it does so by the name `TurboFloat.dll`. I attempted to rename both to `myfloat.lib` and `myfloat.dll` but it still searches for `TurboFloat.dll`.

Am I understanding you correctly in that what needs to happen is..

1. To not link with `TurboFloat.lib`
2. And instead call `LoadLibrary` on the dll directly
3. Followed by `GetProcAddress` for each function of TurboFloat?

Thanks, that works for the time being. My distribution and presentation has temporarily changed in anticipation of a combined TurboFloat and TurboActivate static build, I'll keep an on this thread for updates.