So your binary is looking for whatever version of ecl lives at @libdir@/libecl.16.1.dylib. I still can't find a definition for the macros, but this https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW21 has a description of how the reference for libeql5.1.dylib will be resolved at runtime.
On 9/26/17 2:06 PM, John Mercouris wrote:
Without performing any changes to the binary, e.g. copying libraries, the output is as follows:
otool -L next.app/Contents/MacOS/next
next.app/Contents/MacOS/next: @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) libeql5.1.dylib (compatibility version 1.0.0, current version 1.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)
-John
On Sep 26, 2017, at 12:56, Joshua Kordani <jkordani@lsa2.com mailto:jkordani@lsa2.com> wrote:
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 >> >>
-
Joshua Kordani