Re: ECL + EQL Standalone Binary

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
>>>>>>
>>>>>>
>>>>
>>>
>>
>