<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, 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="">jmercouris@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" 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="">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></div></div></blockquote></div><br class=""></div></body></html>