Trying to compile TurboActivate into an MacOS 64 App – getting E2597 Undefined symbols for architecture x86_64:

  

during the linking stage of compilation – I get this error

[dccosx64 Error] E2597 Undefined symbols for architecture x86_64:

Error: “__TA_GetHandle”, referenced from: __ZN17Turboactivateunit12TA_GetHandleEPc in TurboActivateUnit.o;
Error: “__TA_CheckAndSavePKey”, referenced from: __ZN17Turboactivateunit19TA_CheckAndSavePKeyEmPcm in TurboActivateUnit.o;
Error: “__TA_PDetsFromPath”, referenced from: __ZN17Turboactivateunit16TA_PDetsFromPathEPc in TurboActivateUnit.o;
Error: “__TA_ActivateFromFile”, referenced from: __ZN17Turboactivateunit19TA_ActivateFromFileEmPc in TurboActivateUnit.o;

.
.
.
.
.
ld: symbol(s) not found for architecture x86_64

In the code the functions are declared like this

function TA_GetHandle(versionGUID: System.PAnsiChar):LongWord; cdecl; external ‘libTurboActivate.dylib’ name ‘_TA_GetHandle’;

function TA_Activate(handle: LongWord; options: Pointer):LongInt; cdecl; external ‘libTurboActivate.dylib’ name ‘_TA_Activate’;

function TA_ActivationRequestToFile(handle: LongWord; filename: System.PAnsiChar; options: Pointer):LongInt; cdecl; external ‘libTurboActivate.dylib’ name ‘_TA_ActivationRequestToFile’;

function TA_ActivateFromFile(handle: LongWord; filename: System.PAnsiChar):LongInt; cdecl; external ‘libTurboActivate.dylib’ name ‘_TA_ActivateFromFile’;
.
.
.
.

I have examined the Dylib file on the Mac using the ‘nm’ tool and got a list of the functions inside the dylib – unfortunately I am note sure how to determine whether the function is 32bit or 64bit as I understand a dylib can contain both version of the function. Am I correct in thinking that the dylib may only contain the 32 bit version of the functions and not the 64?
I have been in touch with Wyday, the creators of the TurboActivate.dylib who very quickly responded with a ‘not our problem’ response.

To Answer Duns Question:

I am afraid not – I contacted Lime support here is there reply:

It’s hard to say what exactly Delphi finds objectionable. libTurboActivate.dylib works perfectly for other programming languages.
Likely bugs in Delphi and / or their support for x64 macOS target (which must be a recent addition to Delphi, because the 10.2 version of Delphi only support x86).
We’ll look at this eventually and see if we can work around Delphi’s bugs. But this is not high priority for us right now. You’d be better off contacting Delphi’s parent company (still Empbarcadero?) and ask them to help you.

I did contact embarcadero who came back with this

Your request has been determined to be beyond scope of our incident-based support services. I recommend checking with the vendor responsible for the support library for assistance.

It would appear that the two vendors are blaming each other which isn’t very helpful at all.

I ended up removing LimeLM from our product and went with a much cruder version of usage control for now. If it doesn’t get fixed we will pursue other forms of product licensing.

Comments are closed.