> On 25 Sep 2017, at 22:47, John Mercouris <jmercou...@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@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__

Reply via email to