Hey everyone,
I’m John (the developer of nEXT (https://github.com/neXT-Browser/nEXT/ https://github.com/neXT-Browser/nEXT/),
I’m trying to produce a standalone binary. I managed to create a “.app” bundle of my application, and then I linked the libraries ecl and eql following this approach (https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-libr... https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-libraries):
install_name_tool -change libeql5.1.dylib @executable_path/../Frameworks/libeql5.1.dylib next.app/Contents/MacOS/next install_name_tool -change @libdir@/libecl.16.1.dylib @executable_path/../Frameworks/libecl.16.1.dylib next.app/Contents/MacOS/next
otool then reveals that everything was successful:
otool -L next.app/Contents/MacOS/next
next.app/Contents/MacOS/next: @executable_path/../Frameworks/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) @executable_path/../Frameworks/libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Anyways, long story short, I got the following terminal output when I try to launch my new app binary:
In order to minimize the possibility of mistakes in my program, misusage of QT etc, I’ve created a branch where I’ve included only 2 lisp files, a package file, and a “base” file:
https://github.com/nEXT-Browser/nEXT/tree/compile/next https://github.com/nEXT-Browser/nEXT/tree/compile/next
Any ideas on how to proceed would be very useful, thank you,
-John
On 25 Sep 2017, at 19:19, John Mercouris jmercouris@gmail.com wrote:
Hey everyone,
I’m John (the developer of nEXT (https://github.com/neXT-Browser/nEXT/ https://github.com/neXT-Browser/nEXT/),
I’m trying to produce a standalone binary. I managed to create a “.app” bundle of my application, and then I linked the libraries ecl and eql following this approach (https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-libr... https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-libraries):
install_name_tool -change libeql5.1.dylib @executable_path/../Frameworks/libeql5.1.dylib next.app/Contents/MacOS/next install_name_tool -change @libdir@/libecl.16.1.dylib @executable_path/../Frameworks/libecl.16.1.dylib next.app/Contents/MacOS/next
otool then reveals that everything was successful:
otool -L next.app/Contents/MacOS/next
next.app/Contents/MacOS/next: @executable_path/../Frameworks/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) @executable_path/../Frameworks/libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Anyways, long story short, I got the following terminal output when I try to launch my new app binary:
<Terminal Output>
In order to minimize the possibility of mistakes in my program, misusage of QT etc, I’ve created a branch where I’ve included only 2 lisp files, a package file, and a “base” file:
https://github.com/nEXT-Browser/nEXT/tree/compile/next https://github.com/nEXT-Browser/nEXT/tree/compile/next
Any ideas on how to proceed would be very useful, thank you,
It looks like the error, which is:
Internal or unrecoverable error in: Got signal before environment was installed on our thread [2: No such file or directory]
;;; ECL C Backtrace ;;; 0 libecl.16.1.dylib 0x00000001031d8512 si_dump_c_backtrace + 66 ;;; 1 libecl.16.1.dylib 0x00000001031cac15 ecl_internal_error + 101 ;;; 2 libecl.16.1.dylib 0x00000001031f0c30 deferred_signal_handler + 0 ;;; 3 libecl.16.1.dylib 0x00000001031f092d sigsegv_handler + 381 ;;; 4 libsystem_platform.dylib 0x00007fffb48d9b3a _sigtramp + 26 ;;; 5 ??? 0x000000000000ffff 0x0 + 65535 ;;; 6 libecl.16.1.dylib 0x0000000105072271 cl_boot + 1025 ;;; 7 next 0x00000001030bb457 main + 23 ;;; 8 libdyld.dylib 0x00007fffb46ca235 start + 1 fish: “/Users/jmercouris/Projects/Next…” terminated by signal SIGABRT (Abort)
is unrelated to the libraries.
To be sure, have a look at the source of cl_boot (around assembly offset 1025) to see what it’s doing there. (You may use lldb to disassemble cl_boot and see what function is called around offset 1025, to help you locate the source of the error).
(Concerning the warnings, did you copy the frameworks to the application package?)
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?
Thanks for your time,
-John
On Sep 25, 2017, at 15:26, Pascal Bourguignon pjb@informatimago.com wrote:
On 25 Sep 2017, at 19:19, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com> wrote:
Hey everyone,
I’m John (the developer of nEXT (https://github.com/neXT-Browser/nEXT/ https://github.com/neXT-Browser/nEXT/),
I’m trying to produce a standalone binary. I managed to create a “.app” bundle of my application, and then I linked the libraries ecl and eql following this approach (https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-libr... https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-libraries):
install_name_tool -change libeql5.1.dylib @executable_path/../Frameworks/libeql5.1.dylib next.app/Contents/MacOS/next install_name_tool -change @libdir@/libecl.16.1.dylib @executable_path/../Frameworks/libecl.16.1.dylib next.app/Contents/MacOS/next
otool then reveals that everything was successful:
otool -L next.app/Contents/MacOS/next
next.app/Contents/MacOS/next: @executable_path/../Frameworks/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) @executable_path/../Frameworks/libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Anyways, long story short, I got the following terminal output when I try to launch my new app binary:
<Terminal Output>
In order to minimize the possibility of mistakes in my program, misusage of QT etc, I’ve created a branch where I’ve included only 2 lisp files, a package file, and a “base” file:
https://github.com/nEXT-Browser/nEXT/tree/compile/next https://github.com/nEXT-Browser/nEXT/tree/compile/next
Any ideas on how to proceed would be very useful, thank you,
It looks like the error, which is:
Internal or unrecoverable error in: Got signal before environment was installed on our thread [2: No such file or directory]
;;; ECL C Backtrace ;;; 0 libecl.16.1.dylib 0x00000001031d8512 si_dump_c_backtrace + 66 ;;; 1 libecl.16.1.dylib 0x00000001031cac15 ecl_internal_error + 101 ;;; 2 libecl.16.1.dylib 0x00000001031f0c30 deferred_signal_handler + 0 ;;; 3 libecl.16.1.dylib 0x00000001031f092d sigsegv_handler + 381 ;;; 4 libsystem_platform.dylib 0x00007fffb48d9b3a _sigtramp + 26 ;;; 5 ??? 0x000000000000ffff 0x0 + 65535 ;;; 6 libecl.16.1.dylib 0x0000000105072271 cl_boot + 1025 ;;; 7 next 0x00000001030bb457 main + 23 ;;; 8 libdyld.dylib 0x00007fffb46ca235 start + 1 fish: “/Users/jmercouris/Projects/Next…” terminated by signal SIGABRT (Abort)
is unrelated to the libraries.
To be sure, have a look at the source of cl_boot (around assembly offset 1025) to see what it’s doing there. (You may use lldb to disassemble cl_boot and see what function is called around offset 1025, to help you locate the source of the error).
(Concerning the warnings, did you copy the frameworks to the application package?)
-- __Pascal J. Bourguignon__
On 25 Sep 2017, at 22:47, John Mercouris 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).
2017-09-25 19:19 GMT+02:00, John Mercouris jmercouris@gmail.com:
Any ideas on how to proceed would be very useful, thank you,
Hi John,
the only thing that currently comes to mind is trying to comment out the line
EQL::ini(argv);
in your main.cpp (this function simply calls cl_boot(); I remember that I needed to place it there in the past, just to be safe on all platforms.
But cl_boot() will also be called later in the EQL constructor (only if it has not been called earlier).
So, maybe in your situation it's better when it's called after the QApplication constructor has been called.
But this is just a guess.
BTW, I tried to compile it on Linux (from the sources given by you), and it worked without problems!
Paul
-John
2017-09-25 19:19 GMT+02:00, John Mercouris jmercouris@gmail.com:
Any ideas on how to proceed would be very useful, thank you,
Another (generic) observation:
It seems that your terminal uses a debugger (automatically?).
If I want to use gdb on Linux, I need a ~/.gdbinit file with these lines:
handle SIGPWR nostop noprint handle SIGXCPU nostop noprint
(Because these signals are used by ECL, and are no errors.)
-John
Hi Paul,
I’ve commented out the line: EQL::ini(argv);
But I still haven’t had any luck with the standalone binary. I can get compilation to work if I don’t move my dylibs into my application bundle. The problem is that it’ll run just fine on my computer, but I can’t easily distribute it because other users would have to still install ECL and EQL.
I’m not sure how it happens, but somehow in the process of copying the dylibs into my application bundle, this causes the program to break and produce this very strange error.
Using the macdeployqt tool to copy the dependencies automatically seems to work with external libraries, at least it works with EQL, what I can’t figure out is why for ECL otool reports:
otool -L next.app/Contents/MacOS/next
@libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0)
I’m not sure what @libdir@ is, probably some make directive, if I run a more verbose form of macdeployqt, I get some interesting output:
macdeployqt ./next.app/ -libpath=/usr/local/lib -verbose=3
Log: Framework name "libecl.16.1.dylib" Framework directory "/@libdir@/" Framework path "/@libdir@/libecl.16.1.dylib" Binary directory "/@libdir@/" Binary name "libecl.16.1.dylib" Binary path "/@libdir@/libecl.16.1.dylib" Version "" Install name "" Deployed install name "@executable_path/../Frameworks/libecl.16.1.dylib" Source file Path "/@libdir@/libecl.16.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/“
The real question I have is, why is ECL reporting such strange directories? Obviously with a directory like: /@libdir@/, macdeployqt doesn’t resolve the proper location to get the dylibs, copy and re-link them.
For EQL it appears to be working perfectly fine:
Log: inspecting "/usr/local/lib/libeql5.1.dylib" Log: Adding framework: Log: Framework name "libeql5.1.dylib" Framework directory "/usr/local/lib/" Framework path "/usr/local/lib/libeql5.1.dylib" Binary directory "/usr/local/lib/" Binary name "libeql5.1.dylib" Binary path "/usr/local/lib/libeql5.1.dylib" Version "" Install name "libeql5.1.dylib" Deployed install name "@executable_path/../Frameworks/libeql5.1.dylib" Source file Path "/usr/local/lib/libeql5.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/"
I have a suspicion that if I can fix this, I can make the binary work. There is absolutely no reason that copying the dylib files should break the binary. One thing that makes me suspicious is that libecl.16.1.dylib is a symlink whereas libeql5.1.dylib is not a symlink. I wanted to make the program use libel.16.1.3.dylib, but I wasn’t sure how to force it to do that,
Anyways, thank you to everyone who has offered your help and support!
-John
------------------------------------------------------------------------ Reference: ------------------------------------------------------------------------ Contents of /usr/local/lib: drwxr-xr-x 55 root wheel 1870 Apr 16 03:55 ecl-16.1.3 -rwxr-xr-x 1 root wheel 3424316 Apr 16 03:55 libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.1.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.dylib -> libecl.16.1.3.dylib -rwxr-xr-x 1 root wheel 11653432 Sep 25 19:58 libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.0.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.dylib -> libeql5.1.0.0.dylib -rwxr-xr-x 1 root wheel 288264 May 1 16:28 libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.0.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.dylib -> libeql5_webkit.1.0.0.dylib
Contents of next.pro QT += widgets printsupport uitools TEMPLATE = app ICON = ../assets/next.icns CONFIG += no_keywords release INCLUDEPATH += /usr/local/include INCLUDEPATH += /usr/local/include/eql LIBS += -L/usr/local/lib -lecl LIBS += -L/usr/local/lib -leql5 LIBS += -L. -lnext TARGET = next DESTDIR = ./ OBJECTS_DIR = ./tmp/ MOC_DIR = ./tmp/
SOURCES += main.cpp
On Sep 26, 2017, at 00:26, PR polos.ruetz@gmail.com wrote:
2017-09-25 19:19 GMT+02:00, John Mercouris jmercouris@gmail.com:
Any ideas on how to proceed would be very useful, thank you,
Hi John,
the only thing that currently comes to mind is trying to comment out the line
EQL::ini(argv);
in your main.cpp (this function simply calls cl_boot(); I remember that I needed to place it there in the past, just to be safe on all platforms.
But cl_boot() will also be called later in the EQL constructor (only if it has not been called earlier).
So, maybe in your situation it's better when it's called after the QApplication constructor has been called.
But this is just a guess.
BTW, I tried to compile it on Linux (from the sources given by you), and it worked without problems!
Paul
-John
The behavior you're seeing r.e @executable_path et al is osx behavior. I can't find a list of all of the supported "macros" but this https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os gives an example of what is going on.
Loosely, executables have the paths to the dylibs they depend on baked into them at compile time. Usually this results in explicit paths being baked in, even if you specified a symbolic link at link time. The final path of the real dylib gets baked into the executable. Osx supports some run time indirection in a few ways, one of which is to allow for macros in the paths to be expanded. Barring an authoritative source for the true meanings, I supposed that @executable_path just causes the dynamic linker to expand that into the path the binary was run from, after which the full pathname to the true location is resolved and the library loaded. Errors here though usually result in "dylib not found errors", but occasionally if this isn't understood, the wrong version of a library could be loaded at runtime, confusing the issue.
On 9/26/17 11:15 AM, John Mercouris wrote:
Hi Paul,
I’ve commented out the line: EQL::ini(argv);
But I still haven’t had any luck with the standalone binary. I can get compilation to work if I don’t move my dylibs into my application bundle. The problem is that it’ll run just fine on my computer, but I can’t easily distribute it because other users would have to still install ECL and EQL.
I’m not sure how it happens, but somehow in the process of copying the dylibs into my application bundle, this causes the program to break and produce this very strange error.
Using the macdeployqt tool to copy the dependencies automatically seems to work with external libraries, at least it works with EQL, what I can’t figure out is why for ECL otool reports:
otool -L next.app/Contents/MacOS/next
@libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0)
I’m not sure what @libdir@ is, probably some make directive, if I run a more verbose form of macdeployqt, I get some interesting output:
macdeployqt ./next.app/ -libpath=/usr/local/lib -verbose=3
Log: Framework name "libecl.16.1.dylib" Framework directory "/@libdir@/" Framework path "/@libdir@/libecl.16.1.dylib" Binary directory "/@libdir@/" Binary name "libecl.16.1.dylib" Binary path "/@libdir@/libecl.16.1.dylib" Version "" Install name "" Deployed install name "@executable_path/../Frameworks/libecl.16.1.dylib" Source file Path "/@libdir@/libecl.16.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/“
The real question I have is, why is ECL reporting such strange directories? Obviously with a directory like: /@libdir@/, macdeployqt doesn’t resolve the proper location to get the dylibs, copy and re-link them.
For EQL it appears to be working perfectly fine:
*Log: inspecting "/usr/local/lib/libeql5.1.dylib"* Log: Adding framework: Log: Framework name "libeql5.1.dylib" Framework directory "/usr/local/lib/" Framework path "/usr/local/lib/libeql5.1.dylib" Binary directory "/usr/local/lib/" Binary name "libeql5.1.dylib" Binary path "/usr/local/lib/libeql5.1.dylib" Version "" Install name "libeql5.1.dylib" Deployed install name "@executable_path/../Frameworks/libeql5.1.dylib" Source file Path "/usr/local/lib/libeql5.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/"
I have a suspicion that if I can fix this, I can make the binary work. There is absolutely no reason that copying the dylib files should break the binary. One thing that makes me suspicious is that libecl.16.1.dylib is a symlink whereas libeql5.1.dylib is not a symlink. I wanted to make the program use libel.16.1.3.dylib, but I wasn’t sure how to force it to do that,
Anyways, thank you to everyone who has offered your help and support!
-John
Reference:
*Contents of /usr/local/lib:* drwxr-xr-x 55 root wheel 1870 Apr 16 03:55 ecl-16.1.3 -rwxr-xr-x 1 root wheel 3424316 Apr 16 03:55 libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.1.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.dylib -> libecl.16.1.3.dylib -rwxr-xr-x 1 root wheel 11653432 Sep 25 19:58 libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.0.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.dylib -> libeql5.1.0.0.dylib -rwxr-xr-x 1 root wheel 288264 May 1 16:28 libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.0.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.dylib -> libeql5_webkit.1.0.0.dylib
*Contents of next.pro* QT += widgets printsupport uitools TEMPLATE = app ICON = ../assets/next.icns CONFIG += no_keywords release INCLUDEPATH += /usr/local/include INCLUDEPATH += /usr/local/include/eql LIBS += -L/usr/local/lib -lecl LIBS += -L/usr/local/lib -leql5 LIBS += -L. -lnext TARGET = next DESTDIR = ./ OBJECTS_DIR = ./tmp/ MOC_DIR = ./tmp/
SOURCES += main.cpp
On Sep 26, 2017, at 00:26, PR <polos.ruetz@gmail.com mailto:polos.ruetz@gmail.com> wrote:
2017-09-25 19:19 GMT+02:00, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com>:
Any ideas on how to proceed would be very useful, thank you,
Hi John,
the only thing that currently comes to mind is trying to comment out the line
EQL::ini(argv);
in your main.cpp (this function simply calls cl_boot(); I remember that I needed to place it there in the past, just to be safe on all platforms.
But cl_boot() will also be called later in the EQL constructor (only if it has not been called earlier).
So, maybe in your situation it's better when it's called after the QApplication constructor has been called.
But this is just a guess.
BTW, I tried to compile it on Linux (from the sources given by you), and it worked without problems!
Paul
-John
Hi Joshua,
Very interesting article that you sent, interested in seeing exactly what the shared libraries were reporting as their names, I got the following:
otool -D libecl.16.1.3.dylib
libecl.16.1.3.dylib: @libdir@/libecl.16.1.dylib
otool -D libeql5.1.0.0.dylib
libeql5.1.0.0.dylib: libeql5.1.dylib
Why is the directive for ECL say @libdir@? Is there a way for me to change it? Should I reinstall ECL in a different way?
-John
On Sep 26, 2017, at 10:45, Joshua Kordani jkordani@lsa2.com wrote:
The behavior you're seeing r.e @executable_path et al is osx behavior. I can't find a list of all of the supported "macros" but this https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os gives an example of what is going on.
Loosely, executables have the paths to the dylibs they depend on baked into them at compile time. Usually this results in explicit paths being baked in, even if you specified a symbolic link at link time. The final path of the real dylib gets baked into the executable. Osx supports some run time indirection in a few ways, one of which is to allow for macros in the paths to be expanded. Barring an authoritative source for the true meanings, I supposed that @executable_path just causes the dynamic linker to expand that into the path the binary was run from, after which the full pathname to the true location is resolved and the library loaded. Errors here though usually result in "dylib not found errors", but occasionally if this isn't understood, the wrong version of a library could be loaded at runtime, confusing the issue.
On 9/26/17 11:15 AM, John Mercouris wrote:
Hi Paul,
I’ve commented out the line: EQL::ini(argv);
But I still haven’t had any luck with the standalone binary. I can get compilation to work if I don’t move my dylibs into my application bundle. The problem is that it’ll run just fine on my computer, but I can’t easily distribute it because other users would have to still install ECL and EQL.
I’m not sure how it happens, but somehow in the process of copying the dylibs into my application bundle, this causes the program to break and produce this very strange error.
Using the macdeployqt tool to copy the dependencies automatically seems to work with external libraries, at least it works with EQL, what I can’t figure out is why for ECL otool reports:
otool -L next.app/Contents/MacOS/next
@libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0)
I’m not sure what @libdir@ is, probably some make directive, if I run a more verbose form of macdeployqt, I get some interesting output:
macdeployqt ./next.app/ -libpath=/usr/local/lib -verbose=3
Log: Framework name "libecl.16.1.dylib" Framework directory "/@libdir@/" Framework path "/@libdir@/libecl.16.1.dylib" mailto:/@libdir@/libecl.16.1.dylib Binary directory "/@libdir@/" Binary name "libecl.16.1.dylib" Binary path "/@libdir@/libecl.16.1.dylib" mailto:/@libdir@/libecl.16.1.dylib Version "" Install name "" Deployed install name "@executable_path/../Frameworks/libecl.16.1.dylib" Source file Path "/@libdir@/libecl.16.1.dylib" mailto:/@libdir@/libecl.16.1.dylib Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/“
The real question I have is, why is ECL reporting such strange directories? Obviously with a directory like: /@libdir@/, macdeployqt doesn’t resolve the proper location to get the dylibs, copy and re-link them.
For EQL it appears to be working perfectly fine:
Log: inspecting "/usr/local/lib/libeql5.1.dylib" Log: Adding framework: Log: Framework name "libeql5.1.dylib" Framework directory "/usr/local/lib/" Framework path "/usr/local/lib/libeql5.1.dylib" Binary directory "/usr/local/lib/" Binary name "libeql5.1.dylib" Binary path "/usr/local/lib/libeql5.1.dylib" Version "" Install name "libeql5.1.dylib" Deployed install name "@executable_path/../Frameworks/libeql5.1.dylib" Source file Path "/usr/local/lib/libeql5.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/"
I have a suspicion that if I can fix this, I can make the binary work. There is absolutely no reason that copying the dylib files should break the binary. One thing that makes me suspicious is that libecl.16.1.dylib is a symlink whereas libeql5.1.dylib is not a symlink. I wanted to make the program use libel.16.1.3.dylib, but I wasn’t sure how to force it to do that,
Anyways, thank you to everyone who has offered your help and support!
-John
Reference:
Contents of /usr/local/lib: drwxr-xr-x 55 root wheel 1870 Apr 16 03:55 ecl-16.1.3 -rwxr-xr-x 1 root wheel 3424316 Apr 16 03:55 libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.1.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.dylib -> libecl.16.1.3.dylib -rwxr-xr-x 1 root wheel 11653432 Sep 25 19:58 libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.0.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.dylib -> libeql5.1.0.0.dylib -rwxr-xr-x 1 root wheel 288264 May 1 16:28 libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.0.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.dylib -> libeql5_webkit.1.0.0.dylib
Contents of next.pro QT += widgets printsupport uitools TEMPLATE = app ICON = ../assets/next.icns CONFIG += no_keywords release INCLUDEPATH += /usr/local/include INCLUDEPATH += /usr/local/include/eql LIBS += -L/usr/local/lib -lecl LIBS += -L/usr/local/lib -leql5 LIBS += -L. -lnext TARGET = next DESTDIR = ./ OBJECTS_DIR = ./tmp/ MOC_DIR = ./tmp/
SOURCES += main.cpp
On Sep 26, 2017, at 00:26, PR <polos.ruetz@gmail.com mailto:polos.ruetz@gmail.com> wrote:
2017-09-25 19:19 GMT+02:00, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com>:
Any ideas on how to proceed would be very useful, thank you,
Hi John,
the only thing that currently comes to mind is trying to comment out the line
EQL::ini(argv);
in your main.cpp (this function simply calls cl_boot(); I remember that I needed to place it there in the past, just to be safe on all platforms.
But cl_boot() will also be called later in the EQL constructor (only if it has not been called earlier).
So, maybe in your situation it's better when it's called after the QApplication constructor has been called.
But this is just a guess.
BTW, I tried to compile it on Linux (from the sources given by you), and it worked without problems!
Paul
-John
Hi Joshua, sorry for the double email, it occurred to me to list the dependencies as well:
otool -L libeql5.1.0.0.dylib
libeql5.1.0.0.dylib: libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0) @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) /opt/local/libexec/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility version 5.8.0, current version 5.8.0) /opt/local/libexec/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.8.0, current version 5.8.0) /opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.8.0, current version 5.8.0) /opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.8.0, current version 5.8.0) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
otool -L libecl.16.1.3.dylib
libecl.16.1.3.dylib: @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1)
Could it be that when I use install_name_tool and change the binary, it cannot find @libdir@/libecl?
-John
On Sep 26, 2017, at 11:30, John Mercouris jmercouris@gmail.com wrote:
Hi Joshua,
Very interesting article that you sent, interested in seeing exactly what the shared libraries were reporting as their names, I got the following:
otool -D libecl.16.1.3.dylib
libecl.16.1.3.dylib: @libdir@/libecl.16.1.dylib
otool -D libeql5.1.0.0.dylib
libeql5.1.0.0.dylib: libeql5.1.dylib
Why is the directive for ECL say @libdir@? Is there a way for me to change it? Should I reinstall ECL in a different way?
-John
On Sep 26, 2017, at 10:45, Joshua Kordani <jkordani@lsa2.com mailto:jkordani@lsa2.com> wrote:
The behavior you're seeing r.e @executable_path et al is osx behavior. I can't find a list of all of the supported "macros" but this https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os gives an example of what is going on.
Loosely, executables have the paths to the dylibs they depend on baked into them at compile time. Usually this results in explicit paths being baked in, even if you specified a symbolic link at link time. The final path of the real dylib gets baked into the executable. Osx supports some run time indirection in a few ways, one of which is to allow for macros in the paths to be expanded. Barring an authoritative source for the true meanings, I supposed that @executable_path just causes the dynamic linker to expand that into the path the binary was run from, after which the full pathname to the true location is resolved and the library loaded. Errors here though usually result in "dylib not found errors", but occasionally if this isn't understood, the wrong version of a library could be loaded at runtime, confusing the issue.
On 9/26/17 11:15 AM, John Mercouris wrote:
Hi Paul,
I’ve commented out the line: EQL::ini(argv);
But I still haven’t had any luck with the standalone binary. I can get compilation to work if I don’t move my dylibs into my application bundle. The problem is that it’ll run just fine on my computer, but I can’t easily distribute it because other users would have to still install ECL and EQL.
I’m not sure how it happens, but somehow in the process of copying the dylibs into my application bundle, this causes the program to break and produce this very strange error.
Using the macdeployqt tool to copy the dependencies automatically seems to work with external libraries, at least it works with EQL, what I can’t figure out is why for ECL otool reports:
otool -L next.app/Contents/MacOS/next
@libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0)
I’m not sure what @libdir@ is, probably some make directive, if I run a more verbose form of macdeployqt, I get some interesting output:
macdeployqt ./next.app/ -libpath=/usr/local/lib -verbose=3
Log: Framework name "libecl.16.1.dylib" Framework directory "/@libdir@/" Framework path "/@libdir@/libecl.16.1.dylib" mailto:/@libdir@/libecl.16.1.dylib Binary directory "/@libdir@/" Binary name "libecl.16.1.dylib" Binary path "/@libdir@/libecl.16.1.dylib" mailto:/@libdir@/libecl.16.1.dylib Version "" Install name "" Deployed install name "@executable_path/../Frameworks/libecl.16.1.dylib" Source file Path "/@libdir@/libecl.16.1.dylib" mailto:/@libdir@/libecl.16.1.dylib Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/“
The real question I have is, why is ECL reporting such strange directories? Obviously with a directory like: /@libdir@/, macdeployqt doesn’t resolve the proper location to get the dylibs, copy and re-link them.
For EQL it appears to be working perfectly fine:
Log: inspecting "/usr/local/lib/libeql5.1.dylib" Log: Adding framework: Log: Framework name "libeql5.1.dylib" Framework directory "/usr/local/lib/" Framework path "/usr/local/lib/libeql5.1.dylib" Binary directory "/usr/local/lib/" Binary name "libeql5.1.dylib" Binary path "/usr/local/lib/libeql5.1.dylib" Version "" Install name "libeql5.1.dylib" Deployed install name "@executable_path/../Frameworks/libeql5.1.dylib" Source file Path "/usr/local/lib/libeql5.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/"
I have a suspicion that if I can fix this, I can make the binary work. There is absolutely no reason that copying the dylib files should break the binary. One thing that makes me suspicious is that libecl.16.1.dylib is a symlink whereas libeql5.1.dylib is not a symlink. I wanted to make the program use libel.16.1.3.dylib, but I wasn’t sure how to force it to do that,
Anyways, thank you to everyone who has offered your help and support!
-John
Reference:
Contents of /usr/local/lib: drwxr-xr-x 55 root wheel 1870 Apr 16 03:55 ecl-16.1.3 -rwxr-xr-x 1 root wheel 3424316 Apr 16 03:55 libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.1.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.dylib -> libecl.16.1.3.dylib -rwxr-xr-x 1 root wheel 11653432 Sep 25 19:58 libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.0.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.dylib -> libeql5.1.0.0.dylib -rwxr-xr-x 1 root wheel 288264 May 1 16:28 libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.0.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.dylib -> libeql5_webkit.1.0.0.dylib
Contents of next.pro QT += widgets printsupport uitools TEMPLATE = app ICON = ../assets/next.icns CONFIG += no_keywords release INCLUDEPATH += /usr/local/include INCLUDEPATH += /usr/local/include/eql LIBS += -L/usr/local/lib -lecl LIBS += -L/usr/local/lib -leql5 LIBS += -L. -lnext TARGET = next DESTDIR = ./ OBJECTS_DIR = ./tmp/ MOC_DIR = ./tmp/
SOURCES += main.cpp
On Sep 26, 2017, at 00:26, PR <polos.ruetz@gmail.com mailto:polos.ruetz@gmail.com> wrote:
2017-09-25 19:19 GMT+02:00, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com>:
Any ideas on how to proceed would be very useful, thank you,
Hi John,
the only thing that currently comes to mind is trying to comment out the line
EQL::ini(argv);
in your main.cpp (this function simply calls cl_boot(); I remember that I needed to place it there in the past, just to be safe on all platforms.
But cl_boot() will also be called later in the EQL constructor (only if it has not been called earlier).
So, maybe in your situation it's better when it's called after the QApplication constructor has been called.
But this is just a guess.
BTW, I tried to compile it on Linux (from the sources given by you), and it worked without problems!
Paul
-John
I cant speak to whether or not ecl is correctly built, but what is the output of otool -L on your app binary?
On 9/26/17 12:32 PM, John Mercouris wrote:
Hi Joshua, sorry for the double email, it occurred to me to list the dependencies as well:
otool -L libeql5.1.0.0.dylib
libeql5.1.0.0.dylib: libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0) @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) /opt/local/libexec/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility version 5.8.0, current version 5.8.0) /opt/local/libexec/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.8.0, current version 5.8.0) /opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.8.0, current version 5.8.0) /opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.8.0, current version 5.8.0) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
otool -L libecl.16.1.3.dylib
libecl.16.1.3.dylib: @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1)
Could it be that when I use install_name_tool and change the binary, it cannot find @libdir@/libecl?
-John
On Sep 26, 2017, at 11:30, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com> wrote:
Hi Joshua,
Very interesting article that you sent, interested in seeing exactly what the shared libraries were reporting as their names, I got the following:
otool -D libecl.16.1.3.dylib
libecl.16.1.3.dylib: @libdir@/libecl.16.1.dylib
otool -D libeql5.1.0.0.dylib
libeql5.1.0.0.dylib: libeql5.1.dylib
Why is the directive for ECL say @libdir@? Is there a way for me to change it? Should I reinstall ECL in a different way?
-John
On Sep 26, 2017, at 10:45, Joshua Kordani <jkordani@lsa2.com mailto:jkordani@lsa2.com> wrote:
The behavior you're seeing r.e @executable_path et al is osx behavior. I can't find a list of all of the supported "macros" but this https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os gives an example of what is going on.
Loosely, executables have the paths to the dylibs they depend on baked into them at compile time. Usually this results in explicit paths being baked in, even if you specified a symbolic link at link time. The final path of the real dylib gets baked into the executable. Osx supports some run time indirection in a few ways, one of which is to allow for macros in the paths to be expanded. Barring an authoritative source for the true meanings, I supposed that @executable_path just causes the dynamic linker to expand that into the path the binary was run from, after which the full pathname to the true location is resolved and the library loaded. Errors here though usually result in "dylib not found errors", but occasionally if this isn't understood, the wrong version of a library could be loaded at runtime, confusing the issue.
On 9/26/17 11:15 AM, John Mercouris wrote:
Hi Paul,
I’ve commented out the line: EQL::ini(argv);
But I still haven’t had any luck with the standalone binary. I can get compilation to work if I don’t move my dylibs into my application bundle. The problem is that it’ll run just fine on my computer, but I can’t easily distribute it because other users would have to still install ECL and EQL.
I’m not sure how it happens, but somehow in the process of copying the dylibs into my application bundle, this causes the program to break and produce this very strange error.
Using the macdeployqt tool to copy the dependencies automatically seems to work with external libraries, at least it works with EQL, what I can’t figure out is why for ECL otool reports:
otool -L next.app/Contents/MacOS/next
@libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0)
I’m not sure what @libdir@ is, probably some make directive, if I run a more verbose form of macdeployqt, I get some interesting output:
macdeployqt ./next.app/ -libpath=/usr/local/lib -verbose=3
Log: Framework name "libecl.16.1.dylib" Framework directory "/@libdir@/" Framework path "/@libdir@/libecl.16.1.dylib" Binary directory "/@libdir@/" Binary name "libecl.16.1.dylib" Binary path "/@libdir@/libecl.16.1.dylib" Version "" Install name "" Deployed install name "@executable_path/../Frameworks/libecl.16.1.dylib" Source file Path "/@libdir@/libecl.16.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/“
The real question I have is, why is ECL reporting such strange directories? Obviously with a directory like: /@libdir@/, macdeployqt doesn’t resolve the proper location to get the dylibs, copy and re-link them.
For EQL it appears to be working perfectly fine:
*Log: inspecting "/usr/local/lib/libeql5.1.dylib"* Log: Adding framework: Log: Framework name "libeql5.1.dylib" Framework directory "/usr/local/lib/" Framework path "/usr/local/lib/libeql5.1.dylib" Binary directory "/usr/local/lib/" Binary name "libeql5.1.dylib" Binary path "/usr/local/lib/libeql5.1.dylib" Version "" Install name "libeql5.1.dylib" Deployed install name "@executable_path/../Frameworks/libeql5.1.dylib" Source file Path "/usr/local/lib/libeql5.1.dylib" Framework Destination Directory (relative to bundle) "Contents/Frameworks/" Binary Destination Directory (relative to bundle) "Contents/Frameworks/"
I have a suspicion that if I can fix this, I can make the binary work. There is absolutely no reason that copying the dylib files should break the binary. One thing that makes me suspicious is that libecl.16.1.dylib is a symlink whereas libeql5.1.dylib is not a symlink. I wanted to make the program use libel.16.1.3.dylib, but I wasn’t sure how to force it to do that,
Anyways, thank you to everyone who has offered your help and support!
-John
Reference:
*Contents of /usr/local/lib:* drwxr-xr-x 55 root wheel 1870 Apr 16 03:55 ecl-16.1.3 -rwxr-xr-x 1 root wheel 3424316 Apr 16 03:55 libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.1.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.16.dylib -> libecl.16.1.3.dylib lrwxr-xr-x 1 jmercouris staff 19 Apr 16 03:55 libecl.dylib -> libecl.16.1.3.dylib -rwxr-xr-x 1 root wheel 11653432 Sep 25 19:58 libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.0.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.1.dylib -> libeql5.1.0.0.dylib lrwxr-xr-x 1 root wheel 19 Sep 25 19:58 libeql5.dylib -> libeql5.1.0.0.dylib -rwxr-xr-x 1 root wheel 288264 May 1 16:28 libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.0.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.1.dylib -> libeql5_webkit.1.0.0.dylib lrwxr-xr-x 1 root wheel 26 May 1 16:28 libeql5_webkit.dylib -> libeql5_webkit.1.0.0.dylib
*Contents of next.pro* QT += widgets printsupport uitools TEMPLATE = app ICON = ../assets/next.icns CONFIG += no_keywords release INCLUDEPATH += /usr/local/include INCLUDEPATH += /usr/local/include/eql LIBS += -L/usr/local/lib -lecl LIBS += -L/usr/local/lib -leql5 LIBS += -L. -lnext TARGET = next DESTDIR = ./ OBJECTS_DIR = ./tmp/ MOC_DIR = ./tmp/
SOURCES += main.cpp
On Sep 26, 2017, at 00:26, PR <polos.ruetz@gmail.com mailto:polos.ruetz@gmail.com> wrote:
2017-09-25 19:19 GMT+02:00, John Mercouris <jmercouris@gmail.com mailto:jmercouris@gmail.com>:
Any ideas on how to proceed would be very useful, thank you,
Hi John,
the only thing that currently comes to mind is trying to comment out the line
EQL::ini(argv);
in your main.cpp (this function simply calls cl_boot(); I remember that I needed to place it there in the past, just to be safe on all platforms.
But cl_boot() will also be called later in the EQL constructor (only if it has not been called earlier).
So, maybe in your situation it's better when it's called after the QApplication constructor has been called.
But this is just a guess.
BTW, I tried to compile it on Linux (from the sources given by you), and it worked without problems!
Paul
-John
-
John Mercouris -
Joshua Kordani -
Pascal Bourguignon -
PR