> On 26 Sep 2017, at 00:41, John Mercouris <jmercou...@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 <p...@informatimago.com >> <mailto:p...@informatimago.com>> wrote: >> >> >> >> >>> On 25 Sep 2017, at 22:47, John Mercouris <jmercou...@gmail.com >>> <mailto: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__ >
