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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> 2017-09-25 19:19 GMT+02:00, John Mercouris <[email protected]
>>>> <mailto:[email protected]>>:
>>>>> 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
>>>>>
>>>>>
>>>
>>
>
