<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Joshua,<div class=""><br class=""></div><div class="">Very interesting article that you sent, interested in seeing exactly what the shared libraries were reporting as their names, I got the following:</div><div class=""><br class=""></div><div class=""><div class="">> otool -D libecl.16.1.3.dylib</div><div class="">libecl.16.1.3.dylib:</div><div class="">@libdir@/libecl.16.1.dylib</div><div class=""><br class=""></div><div class="">> otool -D libeql5.1.0.0.dylib</div><div class="">libeql5.1.0.0.dylib:</div><div class="">libeql5.1.dylib</div></div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">-John</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 26, 2017, at 10:45, Joshua Kordani <<a href="mailto:jkordani@lsa2.com" class="">jkordani@lsa2.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="">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 <a moz-do-not-send="true" href="https://blogs.oracle.com/dipol/dynamic-libraries,-rpath,-and-mac-os" class="">this</a>
gives an example of what is going on.</p><p class="">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.<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 9/26/17 11:15 AM, John Mercouris
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:C43AE238-A4D5-402C-8087-3E1A63B9BA85@gmail.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Hi Paul,
<div class=""><br class="">
</div>
<div class="">I’ve commented out the line: EQL::ini(argv);</div>
<div class="">
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">> otool -L next.app/Contents/MacOS/next</div>
<div class="">@libdir@/libecl.16.1.dylib (compatibility version
16.1.3, current version 0.0.0)</div>
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">> macdeployqt ./next.app/
-libpath=/usr/local/lib -verbose=3</div>
<div class="">Log: Framework name "libecl.16.1.dylib"</div>
<div class=""> Framework directory "/@libdir@/"</div>
<div class=""> Framework path <a class="moz-txt-link-rfc2396E" href="mailto:/@libdir@/libecl.16.1.dylib">"/@libdir@/libecl.16.1.dylib"</a></div>
<div class=""> Binary directory "/@libdir@/"</div>
<div class=""> Binary name "libecl.16.1.dylib"</div>
<div class=""> Binary path <a class="moz-txt-link-rfc2396E" href="mailto:/@libdir@/libecl.16.1.dylib">"/@libdir@/libecl.16.1.dylib"</a></div>
<div class=""> Version ""</div>
<div class=""> Install name ""</div>
<div class=""> Deployed install name
"@executable_path/../Frameworks/libecl.16.1.dylib"</div>
<div class=""> Source file Path <a class="moz-txt-link-rfc2396E" href="mailto:/@libdir@/libecl.16.1.dylib">"/@libdir@/libecl.16.1.dylib"</a></div>
<div class=""> Framework Destination Directory (relative to
bundle) "Contents/Frameworks/"</div>
<div class=""> Binary Destination Directory (relative to bundle)
"Contents/Frameworks/“</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">For EQL it appears to be working perfectly fine:</div>
<div class="">
<div class=""><br class="">
</div>
<div class=""><b class="">Log: inspecting
"/usr/local/lib/libeql5.1.dylib"</b></div>
<div class="">Log: Adding framework:</div>
<div class="">Log: Framework name "libeql5.1.dylib"</div>
<div class=""> Framework directory "/usr/local/lib/"</div>
<div class=""> Framework path "/usr/local/lib/libeql5.1.dylib"</div>
<div class=""> Binary directory "/usr/local/lib/"</div>
<div class=""> Binary name "libeql5.1.dylib"</div>
<div class=""> Binary path "/usr/local/lib/libeql5.1.dylib"</div>
<div class=""> Version ""</div>
<div class=""> Install name "libeql5.1.dylib"</div>
<div class=""> Deployed install name
"@executable_path/../Frameworks/libeql5.1.dylib"</div>
<div class=""> Source file Path
"/usr/local/lib/libeql5.1.dylib"</div>
<div class=""> Framework Destination Directory (relative to
bundle) "Contents/Frameworks/"</div>
<div class=""> Binary Destination Directory (relative to
bundle) "Contents/Frameworks/"</div>
</div>
<div class=""><br class="">
</div>
<div class="">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,</div>
<div class=""><br class="">
</div>
<div class="">Anyways, thank you to everyone who has offered
your help and support!</div>
<div class=""><br class="">
</div>
<div class="">-John</div>
<div class=""><br class="">
</div>
<div class="">------------------------------------------------------------------------</div>
<div class="">Reference:</div>
<div class="">------------------------------------------------------------------------</div>
<div class=""><b class="">Contents of /usr/local/lib:</b></div>
<div class="">
<div class="">drwxr-xr-x 55 root wheel 1870 Apr
16 03:55 ecl-16.1.3</div>
<div class="">-rwxr-xr-x 1 root wheel 3424316 Apr
16 03:55 libecl.16.1.3.dylib</div>
<div class="">lrwxr-xr-x 1 jmercouris staff 19 Apr
16 03:55 libecl.16.1.dylib -> libecl.16.1.3.dylib</div>
<div class="">lrwxr-xr-x 1 jmercouris staff 19 Apr
16 03:55 libecl.16.dylib -> libecl.16.1.3.dylib</div>
<div class="">lrwxr-xr-x 1 jmercouris staff 19 Apr
16 03:55 libecl.dylib -> libecl.16.1.3.dylib</div>
<div class="">-rwxr-xr-x 1 root wheel 11653432 Sep
25 19:58 libeql5.1.0.0.dylib</div>
<div class="">lrwxr-xr-x 1 root wheel 19 Sep
25 19:58 libeql5.1.0.dylib -> libeql5.1.0.0.dylib</div>
<div class="">lrwxr-xr-x 1 root wheel 19 Sep
25 19:58 libeql5.1.dylib -> libeql5.1.0.0.dylib</div>
<div class="">lrwxr-xr-x 1 root wheel 19 Sep
25 19:58 libeql5.dylib -> libeql5.1.0.0.dylib</div>
<div class="">-rwxr-xr-x 1 root wheel 288264 May
1 16:28 libeql5_webkit.1.0.0.dylib</div>
<div class="">lrwxr-xr-x 1 root wheel 26 May
1 16:28 libeql5_webkit.1.0.dylib ->
libeql5_webkit.1.0.0.dylib</div>
<div class="">lrwxr-xr-x 1 root wheel 26 May
1 16:28 libeql5_webkit.1.dylib ->
libeql5_webkit.1.0.0.dylib</div>
<div class="">lrwxr-xr-x 1 root wheel 26 May
1 16:28 libeql5_webkit.dylib ->
libeql5_webkit.1.0.0.dylib</div>
</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Contents of next.pro</b></div>
<div class="">
<div class="">QT += widgets printsupport uitools</div>
<div class="">TEMPLATE = app</div>
<div class="">ICON = ../assets/next.icns</div>
<div class="">CONFIG += no_keywords release</div>
<div class="">INCLUDEPATH += /usr/local/include</div>
<div class="">INCLUDEPATH += /usr/local/include/eql</div>
<div class="">LIBS += -L/usr/local/lib -lecl</div>
<div class="">LIBS += -L/usr/local/lib -leql5</div>
<div class="">LIBS += -L. -lnext</div>
<div class="">TARGET = next</div>
<div class="">DESTDIR = ./</div>
<div class="">OBJECTS_DIR = ./tmp/</div>
<div class="">MOC_DIR = ./tmp/</div>
<div class=""><br class="">
</div>
<div class="">SOURCES += main.cpp</div>
<div class=""><br class="">
</div>
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">On Sep 26, 2017, at 00:26, PR <<a href="mailto:polos.ruetz@gmail.com" class="" moz-do-not-send="true">polos.ruetz@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">2017-09-25 19:19 GMT+02:00, John Mercouris
<<a href="mailto:jmercouris@gmail.com" class="" moz-do-not-send="true">jmercouris@gmail.com</a>>:<br class="">
<blockquote type="cite" class="">Any ideas on how to
proceed would be very useful, thank you,<br class="">
</blockquote>
<br class="">
Hi John,<br class="">
<br class="">
the only thing that currently comes to mind is trying to
comment out the line<br class="">
<br class="">
EQL::ini(argv);<br class="">
<br class="">
in your main.cpp (this function simply calls cl_boot();
I remember<br class="">
that I needed to place it there in the past, just to be
safe on all<br class="">
platforms.<br class="">
<br class="">
But cl_boot() will also be called later in the EQL
constructor (only<br class="">
if it has not been called earlier).<br class="">
<br class="">
So, maybe in your situation it's better when it's called
after the<br class="">
QApplication constructor has been called.<br class="">
<br class="">
But this is just a guess.<br class="">
<br class="">
BTW, I tried to compile it on Linux (from the sources
given by you),<br class="">
and it worked without problems!<br class="">
<br class="">
Paul<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class=""><br class="">
-John<br class="">
<br class="">
<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></div></body></html>