Re: ECL + EQL Standalone Binary

So your binary is looking for whatever version of ecl lives at 
@libdir@/libecl.16.1.dylib.  I still can't find a definition for the 
macros, but this 
<https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW21> 
has a description of how the reference for libeql5.1.dylib will be 
resolved at runtime.


On 9/26/17 2:06 PM, John Mercouris wrote:
> Without performing any changes to the binary, e.g. copying libraries, 
> the output is as follows:
>
> > otool -L next.app/Contents/MacOS/next
> next.app/Contents/MacOS/next:
> @libdir@/libecl.16.1.dylib (compatibility version 16.1.3, current 
> version 0.0.0)
> libeql5.1.dylib (compatibility version 1.0.0, current version 1.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)
>
> -John
>> On Sep 26, 2017, at 12:56, Joshua Kordani <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>> I cant speak to whether or not ecl is correctly built, but what is 
>> the output of otool -L on your app binary?
>>
>>
>> On 9/26/17 12:32 PM, John Mercouris wrote:
>>> 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] 
>>>> <mailto:[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"
>>>>>>  Binary directory "/@libdir@/"
>>>>>>  Binary name "libecl.16.1.dylib"
>>>>>>  Binary path "/@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"
>>>>>>  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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>