ECL + EQL Standalone Binary

Tue Sep 26 14:46:24 UTC 2017

John,

I think Pascal means that you will need to use (cffi:load-library 
"path/to/library") in your code, and if you happen to bundle your dylibs 
with your .app then you can at least find them there.  One problem that 
I haven't found a good answer to is if your libs have explicit path 
references to other libraries, with otool -L.  I would assume you would 
need to use a tool to rewrite the library names so that they are all 
consistent for your desired deployment target fs paths and libs.  If I 
am wrong someone please correct me.

Josh Kordani

On 9/25/17 7:15 PM, John Mercouris wrote:
> Hi Pascal,
>
> If I don’t use the install_name_tool, and I just leave the compiled 
> binary without changing the paths to QT or anything, it all runs fine.
> The issue is, I need to copy the libraries into my application bundle 
> to make it easy to distribute for OS X,
>
> Can you explain what you mean how I may load the libraries at 
> run-time? I looked up CFFI and all I came up with was C Foreign 
> Function Interface,
>
> Thanks for your help,
>
> -John
>> On Sep 25, 2017, at 18:07, Pascal Bourguignon <pjb at informatimago.com 
>> <mailto:pjb at informatimago.com>> wrote:
>>
>>
>>> On 26 Sep 2017, at 00:41, John Mercouris <jmercouris at gmail.com 
>>> <mailto:jmercouris at gmail.com>> wrote:
>>>
>>> Hi Pascal, I’ve done exactly as you said and have the following output:
>>>
>>> <output.pdf>
>>
>> (format nil "~x"(+ 1025 #xe70))  —> "1271"
>>
>> Since it looks like the functions around this address are unrelated 
>> to file accesses, then we may suppose that we have an error due to 
>> the modifications made by install_name_tool to the binary.
>>
>>
>> Try without using this tool.
>>
>> If my hypothesis is correct, you will have to load the libraries 
>> explicitely at run-time as we’ve always done with cffi…
>>
>>
>>
>>> Honestly, I’m not sure what to make of it, it looks very similar to 
>>> your output as well,
>>>
>>> -John
>>>> On Sep 25, 2017, at 16:58, Pascal Bourguignon 
>>>> <pjb at informatimago.com <mailto:pjb at informatimago.com>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On 25 Sep 2017, at 22:47, John Mercouris <jmercouris at gmail.com 
>>>>> <mailto:jmercouris at gmail.com>> wrote:
>>>>>
>>>>> Hi Pascal,
>>>>>
>>>>> Thank you for your email,
>>>>>
>>>>> 1. You’re correct, I had to manually copy the libraries in to the 
>>>>> app bundle, I just did something like:
>>>>>
>>>>>  > cp /usr/local/lib/libeql5.1.dylib ./next.app/Contents/Frameworks/
>>>>>
>>>>> 2. I saw the message is within ECL, I found the exact file with 
>>>>> the error message, it is located in ecl/src/c/unixint.d
>>>>>
>>>>> I figured my problem was unrelated to the libraries, but I wasn’t 
>>>>> 100% sure, just wanted to include all information,
>>>>>
>>>>> 3. I have no idea how to read assembly, I mean I can pick through 
>>>>> it, but I won’t be able to really understand what’s going on, nor 
>>>>> would I know how to even attach a debugger to the process, are 
>>>>> there any other ways that I can examine what’s going on? A source 
>>>>> file I can look at? Should I be looking for issues within ECL or EQL?
>>>>
>>>> You don’t need to understand the assembly code; you can just watch 
>>>> the name of the functions around the indicated location.
>>>>
>>>> In the case of my version of libecl, I would find:
>>>>
>>>> [pjb at despina :0.0 documentation]$ otool -t -v -V 
>>>>  /opt/local/lib/libecl.dylib|grep -A300 -e '^_cl_boot:'
>>>> _cl_boot:
>>>> 0000000000001d34movl0x22ddce(%rip), %eax
>>>> 0000000000001d3atestl%eax, %eax
>>>>
>>>> #x1d34 + 1025 = #x2135
>>>>
>>>> 00000000000020e2callq0x151748 ## symbol stub for: _si_getcwd
>>>> 00000000000020e7movq%rax, 0x708(%r13)
>>>> 00000000000020eemovl$0x1003, %esi
>>>> 00000000000020f3movl$0x1, %edx
>>>> 00000000000020f8movl$0x1, %ecx
>>>> 00000000000020fdmovl$0x1, %r8d
>>>> 0000000000002103movl$0x1, %r9d
>>>> 0000000000002109movq%r14, %rdi
>>>> 000000000000210ccallq0x151814 ## symbol stub for: _si_make_vector
>>>> 0000000000002111movq%rax, 0x250(%r15)
>>>> 0000000000002118movl$0x4, %esi
>>>> 000000000000211dmovl$0x3, %edx
>>>> 0000000000002122movl$0x1, %ecx
>>>> 0000000000002127movq%rax, %rdi
>>>> 000000000000212acallq0x15163a ## symbol stub for: 
>>>> _si_fill_array_with_elt
>>>> 000000000000212fmovq0x250(%r15), %rax
>>>> 0000000000002136movq0x10(%rax), %rcx
>>>> 000000000000213amovq%rcx, 0x240(%r15)
>>>> 0000000000002141movq0x20(%rax), %rax
>>>> 0000000000002145movq%rax, 0x248(%r15)
>>>> 000000000000214cmovq0x320(%r15), %rax
>>>> 0000000000002153movq%rax, 0x134b0(%r13)
>>>> 000000000000215amovq0x22dbef(%rip), %rdx
>>>> 0000000000002161movq0x22dbf0(%rip), %rcx
>>>> 0000000000002168leaq0x4980(%r13), %rdi
>>>> 000000000000216fmovl$0x203, %esi
>>>> 0000000000002174callq0x150026 ## symbol stub for: _cl__make_hash_table
>>>> 0000000000002179movq%rax, %r15
>>>> 000000000000217cmovq%r15, 0x22daad(%rip)
>>>> 0000000000002183leaq_char_names(%rip), %rbx
>>>>
>>>> we can see that calls to SI:GETCWD, SI:MAKE-VECTOR and 
>>>> SI-FILL-ARRAY-WITH-ELT are made just before that address, and a 
>>>> call to CL:MAKE-HASH-TABLE will be called just after.
>>>>
>>>> So if I had the error at the same cl_boot+1025 offset, I would 
>>>> infer there’s some problem with the allocation of a vector.
>>>> (But this is not consistent with your file not found error, so 
>>>> check your own copy of the library, you may find other functions 
>>>> around the cl_boot+1025 address).
>>>>
>>>>
>>>> -- 
>>>> __Pascal J. Bourguignon__
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20170926/aa0fa1c5/attachment-0001.html>