This may be more complicated, but I’ll keep this brief. Also, I KNOW this is a REAL question not Xojo, please no “just upgrade to Xojo” answers.
I sell a popular program that I compile in REAL 2011r3. It uses a dylib that I compile in XCode 3.26. It works wonderfully for most users, from OSX 10.4 to Sierra. Lately it hasn’t for some groups of people, I’ll just focus on one instance here.
One of the first things the app does is call my custom dylib with a function that sets it up. If it fails - it never should - a dialog comes up telling there’s a problem and then quits the app. In case it fails, it’s always the Function Not Found exception, which is the basic error REAL shows when can’t load the dylib fo some reason, not necessarily that the function can’t be found.
One client running OSX 10.11 El Capitan is reporting this problem. I asked him to give me the Console results and my own apps Logs. My app’s logs tell me that it’s receiving the Function Not Found exception. Below is the Console log. The Gestalt thing is normal, just a warning AFAIK and this is a fault of REAL2011r3. But it’s the SecTaskLoadEntitlements error that interests me. I do not know if that is actually the response to the dylib problem, but it is unusual. Any thoughts?
08.12.16 16:43:12.012 Translator 6: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.6 instead of 10.11.6. This is not a bug in Gestalt – it is a documented limitation. Use NSProcessInfo’s operatingSystemVersion property to get correct system version number.
08.12.16 16:43:12.012 Translator 6: 0 CarbonCore 0x06082e3d ___Gestalt_SystemVersion_block_invoke + 135
08.12.16 16:43:12.012 Translator 6: 1 libdispatch.dylib 0x04ba183f _dispatch_client_callout + 50
08.12.16 16:43:12.012 Translator 6: 2 libdispatch.dylib 0x04ba171b dispatch_once_f + 78
08.12.16 16:43:12.012 Translator 6: 3 libdispatch.dylib 0x04ba2fa5 dispatch_once + 31
08.12.16 16:43:12.012 Translator 6: 4 CarbonCore 0x05ffe8e1 _Gestalt_SystemVersion + 1047
08.12.16 16:43:12.012 Translator 6: 5 CarbonCore 0x05ffe08a Gestalt + 154
08.12.16 16:43:12.012 Translator 6: 6 rbframework.dylib 0x01bc75c3 _Z11InitGlobalsv + 43
08.12.16 16:43:12.215 launchservicesd: SecTaskLoadEntitlements failed error=22
08.12.16 16:43:12.221 launchservicesd: SecTaskLoadEntitlements failed error=22
08.12.16 16:43:12.375 appleeventsd: SecTaskLoadEntitlements failed error=22
I found this answer on StackExchange: http://apple.stackexchange.com/a/237483
What entitlements are you giving your application when you sign it?
What does your app do that it might need entitlements?
This is more likely a result of using the wrong gestalt selectors
Apple long ago provided 3 for this reason
// as of 10.4 apple provides 3 selectors so we can
// get the correct version number for things like 10.4.11
Dim sysMajorVersion,sysMinorVersion,sysBugVersion As Integer
call System.Gestalt("sys1", sysMajorVersion)
call System.Gestalt("sys2", sysMinorVersion)
call System.Gestalt("sys3", sysBugVersion)
I read the StackExchange thing. To test, I created a super basic app, made only to access the dylib (“load” it). Same results.
So, to the entitlements, I’m not even signing my app, the real one nor the harness. The client has his security settings set to ignore any warnings. It’s not sold through MAS or anything like that. Perhaps I will be lectured for this, and that’s fine (fire away!), but to the point, why would the app run but then not be able to load/access the dylib?
Just out of curiosity… are you using a Soft Declare to access the functions in your dylib?
Strike that. Read the section on Soft Declares on this page. I think it’ll answer your question.
SecTaskLoadEntitlements error 22 might mean that launchd started the app with an invalid parameter.
Greg, the IsFunctionAvailable returns False. I took the Library Name and the Function Name directly from the Declare, and I am using Soft Declares.
BTW, and not to complicate this, my client is getting this issue on El Capitan. What I am actually testing this on is OSX 10.5, where all of a sudden the dylib never loads either, even though it used to a couple months ago and with no changes in the XCode library build settings.
Make sure that your library is 32-Bit, I had a situation where a custom plugin I had developed was being compiled as 64-Bit (even though I didn’t recall ever switching it to 64-Bit in Xcode).
You should also make sure that you use a relative path to the library, so if it’s stored in the frameworks folder the path should be.
It’s also been a very long time since I’ve done anything like that, so I might be a little rusty.
No, that’s not it either, it’s 32-bit all the way.
So this isn’t really a RWEAL/Xojo problem, it’s a XCode 3.26 dylib problem. I guess I should rephrase, how can one test why a dylib is not loading? What error messages are available and what tools are available to check?
[quote=304073:@Garth Hjelte]No, that’s not it either, it’s 32-bit all the way.
So this isn’t really a RWEAL/Xojo problem, it’s a XCode 3.26 dylib problem. I guess I should rephrase, how can one test why a dylib is not loading? What error messages are available and what tools are available to check?[/quote]
I’d look in the Console when loading your app. If there are any errors, I’d expect to see them there.
Thanks for sticking with this, Greg. I know this is not a REAL/Xojo problem at this point. No, there’s nothing relevant in the Console. In 10.5, something only shows under ‘system.log’ and I see the lines I write into the log only., nothing from anything else.
Hey, I found the solution to my issue - not in not loading in El Capitan, but in not loading in 10.5 and lower.
In my dylib in XCode, I had created a very large design-time buffer - about 100mb. Sort of looking like ‘long ThisBuffer;’ I had this earlier as something like a 40mb buffer, but I’d enlarged it. In this case I wasn’t interested in creating a dynamic buffer because it’s always being used and I didn’t want the constant allocating/deallocating that fragments memory and causes allocation failures down the road. (These are the issues you confront when you DON’T use Xojo!)
Apparently either 10.5/4 - or REAL/Xojo? - has problems loading a dylib that has those internal requirements. It’d be interesting to know if this is a REAL/Xojo problem or it’s a OS problem.
BTW, this thread was about “not loading in 10.11 or higher”, but as time goes on I think that was a special case with one user, and probably this memory-need of the dylib may have raised it’s head. Perhaps it’s all the same issue, so I’m going back and coding a better way to do this buffer in C++.