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,

On Sep 25, 2017, at 18:07, Pascal Bourguignon <> wrote:

On 26 Sep 2017, at 00:41, John Mercouris <> wrote:

Hi Pascal, I’ve done exactly as you said and have the following output:


(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,

On Sep 25, 2017, at 16:58, Pascal Bourguignon <> wrote:

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

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:'
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__