<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I cant speak to whether or not ecl is correctly built, but what
is the output of otool -L on your app binary?<br>
</p>
<br>
<div class="moz-cite-prefix">On 9/26/17 12:32 PM, John Mercouris
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:A7A9175B-467D-41F4-9353-AACCD76F8AE0@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi Joshua, sorry for the double email, it occurred to me to list
the dependencies as well:
<div class=""><br class="">
</div>
<div class="">
<div class="">> otool -L libeql5.1.0.0.dylib</div>
<div class="">libeql5.1.0.0.dylib:</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>libeql5.1.dylib
(compatibility version 1.0.0, current version 1.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@libdir@/libecl.16.1.dylib
(compatibility version 16.1.3, current version 0.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/opt/local/libexec/qt5/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
(compatibility version 5.8.0, current version 5.8.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/opt/local/libexec/qt5/lib/QtWidgets.framework/Versions/5/QtWidgets
(compatibility version 5.8.0, current version 5.8.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/opt/local/libexec/qt5/lib/QtGui.framework/Versions/5/QtGui
(compatibility version 5.8.0, current version 5.8.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore
(compatibility version 5.8.0, current version 5.8.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
(compatibility version 1.0.0, current version 1.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
(compatibility version 1.0.0, current version 275.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libc++.1.dylib
(compatibility version 1.0.0, current version 400.9.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libSystem.B.dylib
(compatibility version 1.0.0, current version 1252.0.0)</div>
<div class="">> otool -L libecl.16.1.3.dylib</div>
<div class="">libecl.16.1.3.dylib:</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@libdir@/libecl.16.1.dylib
(compatibility version 16.1.3, current version 0.0.0)</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libSystem.B.dylib
(compatibility version 1.0.0, current version 1238.51.1)</div>
<div class=""><br class="">
</div>
<div class="">Could it be that when I use install_name_tool and
change the binary, it cannot find @libdir@/libecl?</div>
<div class=""><br class="">
</div>
<div class="">-John</div>
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On Sep 26, 2017, at 11:30, John Mercouris <<a
href="mailto:jmercouris@gmail.com" class=""
moz-do-not-send="true">jmercouris@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div 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 class="">
<blockquote type="cite" class="">
<div class="">On Sep 26, 2017, at 10:45, Joshua
Kordani <<a href="mailto:jkordani@lsa2.com"
class="" moz-do-not-send="true">jkordani@lsa2.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div 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=""> 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"
moz-do-not-send="true">"/@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"
moz-do-not-send="true">"/@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"
moz-do-not-send="true">"/@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>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>