On 26 Sep 2017, at 00:41, John Mercouris jmercouris@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@informatimago.com mailto:pjb@informatimago.com> wrote:
On 25 Sep 2017, at 22:47, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com> wrote:
Hi Pascal,
Thank you for your email,
- 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/
- 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,
- 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__
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@informatimago.com wrote:
On 26 Sep 2017, at 00:41, John Mercouris <jmercouris@gmail.com mailto:jmercouris@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@informatimago.com mailto:pjb@informatimago.com> wrote:
On 25 Sep 2017, at 22:47, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com> wrote:
Hi Pascal,
Thank you for your email,
- 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/
- 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,
- 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__
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@informatimago.com mailto:pjb@informatimago.com> wrote:
On 26 Sep 2017, at 00:41, John Mercouris <jmercouris@gmail.com mailto:jmercouris@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@informatimago.com mailto:pjb@informatimago.com> wrote:
On 25 Sep 2017, at 22:47, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com> wrote:
Hi Pascal,
Thank you for your email,
- 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/
- 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,
- 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: 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__
-
John Mercouris -
Joshua Kordani -
Pascal Bourguignon