It's 32 bit?
Sent from my iPhone
> On 15 Apr 2016, at 1:07 PM, Dar Scott <d...@swcp.com> wrote:
>
> Thanks, Monte!
>
> However, I still have the same error message, so my problem seems to be
> something else.
>
> I poked at it a bit.
>
> The error message seems to be in script-instance.cpp. Looking at that, it
> seems that dlopen is used. I don't have environment variables for dlopen,
> the best I can tell. The man page for dlopen says that the backup
> environment variable does not exist, it is assumed to be
> "$HOME/lib:/usr/local/lib:/usr/lib". Since the last is one of the places
> that I put the library, then I'm guessing the location is probably OK. There
> might be some other dependency I'm not aware of that is causing a problem.
>
> So, there must be something wrong with my .dylib reference. I'll look into
> that.
>
> Dar
>
>
>> On Apr 14, 2016, at 5:30 PM, Monte Goulding <mo...@appisle.net> wrote:
>>
>> Hi Dar!
>>
>> The dylib should be found if it is in resources/code/mac/
>>
>> // This is the callback given to libscript so that it can resolve the
>> absolute
>> // path of native code libraries used by foreign handlers in the module. At
>> // the moment we use the resources path of the module, however it will need
>> to be
>> // changed to a separate location at some point with explicit declaration so
>> that
>> // iOS linkage and Android placement issues can be resolved.
>> //
>> // Currently it expects:
>> // <resources>
>> // code/
>> // mac/<name>.dylib
>> // linux-x86/<name>.so
>> // linux-x86_64/<name>.so
>> // win-x86/<name>.dll
>> //
>> static bool MCEngineResolveSharedLibrary(MCScriptModuleRef p_module,
>> MCStringRef p_name, MCStringRef& r_path)
>> {
>> // If the module has no resource path, then it has no code.
>> MCAutoStringRef t_resource_path;
>> if (!MCEngineLookupResourcePathForModule(p_module, Out(t_resource_path)))
>> return false;
>>
>> if (MCStringIsEmpty(*t_resource_path))
>> return false;
>>
>> #if defined(_MACOSX)
>> return MCStringFormat(r_path, "%@/code/mac/%@.dylib", *t_resource_path,
>> p_name);
>> #elif defined(_LINUX) && defined(__32_BIT__)
>> return MCStringFormat(r_path, "%@/code/linux-x86/%@.so", *t_resource_path,
>> p_name);
>> #elif defined(_LINUX) && defined(__64_BIT__)
>> return MCStringFormat(r_path, "%@/code/linux-x86_64/%@.so",
>> *t_resource_path, p_name);
>> #elif defined(_WINDOWS)
>> return MCStringFormat(r_path, "%@/code/win-x86/%@.dll", *t_resource_path,
>> p_name);
>> #else
>> return false;
>> #endif
>> }
>>
>>
>> Cheers
>>
>> Monte
>>
>>> On 15 Apr 2016, at 9:10 AM, Dar Scott <d...@swcp.com> wrote:
>>>
>>> I want to see the "Widgets by Dar" collection, too! I'm not sure if I want
>>> the snap-together widgets or the "who needs LabView when you have LiveCode"
>>> widgets first. I might start with some libraries.
>>>
>>> And I still haven't solved the issue with this error message. I've tried
>>> putting my dynamic library everywhere and even popped it out of its own
>>> folder.
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
