LimeLM
wyBuild
Support forum
Wyatt Says...
wyDay Home

Using TurboActivate & TurboFloat on macOS (Mac OS X)

TurboActivate and TurboFloat run natively on macOS (see requirements) and you can use it from any programming language. This article will show you some tips and tricks specific to macOS. You should use this article alongside one of the following:

Before you can do anything you need to login to your LimeLM account (or sign up) and download the TurboActivate-Mac.zip. This zip contains the libTurboActivate.dylib along with source code examples.

"TurboActivate.dat" location

TurboActivate loads the "TurboActivate.dat" file from the same directory as the executable. If you want to load the "TurboActivate.dat" file from a directory other than the one the executable's path, then use the TA_PDetsFromPath() function.

Adding "libTurboActivate.dylib" to your application bundle

If you're making a C, C++, or Objective-C app (and you're not using the static library version of TurboActivate) then you need to make sure your application can find the "libTurboActivate.dylib" file at runtime. In Xcode you can do this by setting the "Runpath Search Paths" project setting:

Set the 'Runpath Search Paths' in Xcode

Use the "@executable_path" variable to load "libTurboActivate.dylib" relative to your app's binary. For instance, if "libTurboActivate.dylib" will be in the same path as your binary then you should set "Runpath Search Paths" to the following:

@executable_path/.

If you want "libTurboActivate.dylib" to be in the "Frameworks" directory of your app bundle, then you can set "Runpath Search Paths" to:

@executable_path/../Frameworks

Other commandline compilers

If you're building your app from commandline use the -rpath linker option. For instance, if you want to load libTurboActivate.dylib from your app's executable path, then the compiler options will look something like the following:

cc -o main ... -Wl,-rpath,@executable_path/.

If you want the *.dylib to be in the "Frameworks" directory in your *.app bundle, then the compiler options will look something like this:

cc -o main ... -Wl,-rpath,@executable_path/../Frameworks

Getting the version number of libTurboActivate.dylib

The version number is embedded in the *.dylib file. You can get it in human readable form by typing the following line in Terminal:

otool -L libTurboActivate.dylib

The output will be several lines long. The version number is on the second line before the closing parentheses. For example:

libTurboActivate.dylib:
    @rpath/libTurboActivate.dylib (compatibility version 1.0.0, current version 4.0.5)
    ...

Verifying the signature

TurboActivate, TurboFloat Library, and the TurboFloat Server for macOS are all code-signed and timestamped. If they're missing this signature then you know the files have been tampered with. You can verify the signature with this command:

codesign -dv --verbose=4 ./libTurboActivate.dylib

You can replace "./libTurboActivate.dylib" with the path of the executable or dynamic library you want to check the signature for. And when you run that command the output you should look for are (a) whether the library or executable is signed at all, and (b) if it's signed by "wyDay, LLC" (see the "Authority" line). Here's example output:

Identifier=libTurboActivate
Format=Mach-O universal (i386 ppc7400 x86_64)
CodeDirectory v=20100 size=6849 flags=0x0(none) hashes=210+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=cafc62e10b27cf6129795bb207afdea1c096338c
CandidateCDHash sha256=694c57294098bb9412007b4b048cd02d1c2d84bd
Hash choices=sha1,sha256
CDHash=694c57294098bb9412007b4b048cd02d1c2d84bd
Signature size=9479
Authority=wyDay, LLC
Authority=DigiCert EV Code Signing CA (SHA2)
Authority=DigiCert High Assurance EV Root CA
Timestamp=Oct 5, 2016, 12:28:53 PM
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=92

Reducing the size of libTurboActivate.dylib

The TurboActivate library "libTurboActivate.dylib" is built as a universal library; it works on Intel Macs (x86 and x64) and PPC Macs. You can use the lipo commandline tool to remove support for platforms you don't need. For example, if you want to remove PPC support:

lipo -remove ppc7400 libTurboActivate.dylib -output libTurboActivate-noPPC.dylib

Then create a backup of the old "libTurboActivate" and replace it with the new PPC-less "libTurboActivate":

mv libTurboActivate.dylib libTurboActivate-all.dylib
mv libTurboActivate-noPPC.dylib libTurboActivate.dylib

Extra frameworks needed to use the static TurboActivateUsing the static library (libTurboActivate.a)

If you're using C, C++, or Objective-C then you also have the option of using the static library version of TurboActivate. In addition to including libTurboActivate.a in your project you also need to add references to the following Frameworks and libraries:

You can do this in XCode by setting the "Other Linker Flags" for the target as the following:

-lc++ -lcurl -framework CoreFoundation -framework CoreServices -framework Foundation -framework IOKit -framework SystemConfiguration