ECL + EQL Standalone Binary

[John Mercouris]

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> 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:
>>> 0000000000001d34	movl	0x22ddce(%rip), %eax
>>> 0000000000001d3a	testl	%eax, %eax
>>> 
>>> #x1d34 + 1025 = #x2135
>>> 
>>> 00000000000020e2	callq	0x151748 ## symbol stub for: _si_getcwd
>>> 00000000000020e7	movq	%rax, 0x708(%r13)
>>> 00000000000020ee	movl	$0x1003, %esi
>>> 00000000000020f3	movl	$0x1, %edx
>>> 00000000000020f8	movl	$0x1, %ecx
>>> 00000000000020fd	movl	$0x1, %r8d
>>> 0000000000002103	movl	$0x1, %r9d
>>> 0000000000002109	movq	%r14, %rdi
>>> 000000000000210c	callq	0x151814 ## symbol stub for: _si_make_vector
>>> 0000000000002111	movq	%rax, 0x250(%r15)
>>> 0000000000002118	movl	$0x4, %esi
>>> 000000000000211d	movl	$0x3, %edx
>>> 0000000000002122	movl	$0x1, %ecx
>>> 0000000000002127	movq	%rax, %rdi
>>> 000000000000212a	callq	0x15163a ## symbol stub for: _si_fill_array_with_elt
>>> 000000000000212f	movq	0x250(%r15), %rax
>>> 0000000000002136	movq	0x10(%rax), %rcx
>>> 000000000000213a	movq	%rcx, 0x240(%r15)
>>> 0000000000002141	movq	0x20(%rax), %rax
>>> 0000000000002145	movq	%rax, 0x248(%r15)
>>> 000000000000214c	movq	0x320(%r15), %rax
>>> 0000000000002153	movq	%rax, 0x134b0(%r13)
>>> 000000000000215a	movq	0x22dbef(%rip), %rdx
>>> 0000000000002161	movq	0x22dbf0(%rip), %rcx
>>> 0000000000002168	leaq	0x4980(%r13), %rdi
>>> 000000000000216f	movl	$0x203, %esi
>>> 0000000000002174	callq	0x150026 ## symbol stub for: _cl__make_hash_table
>>> 0000000000002179	movq	%rax, %r15
>>> 000000000000217c	movq	%r15, 0x22daad(%rip)
>>> 0000000000002183	leaq	_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/20170925/39a56ed7/attachment.html>