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 <jkord...@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.ru...@gmail.com >>> <mailto:polos.ru...@gmail.com>> wrote: >>> >>> 2017-09-25 19:19 GMT+02:00, John Mercouris <jmercou...@gmail.com >>> <mailto:jmercou...@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 >>>> >>>> >> >
