ECL + EQL Standalone Binary
Joshua Kordani
jkordani at lsa2.com
Tue Sep 26 18:29:28 UTC 2017
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 <jkordani at lsa2.com
>> <mailto:jkordani at lsa2.com>> 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 <jmercouris at gmail.com
>>>> <mailto:jmercouris at gmail.com>> 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 <jkordani at lsa2.com
>>>>> <mailto:jkordani at lsa2.com>> 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 <polos.ruetz at gmail.com
>>>>>>> <mailto:polos.ruetz at gmail.com>> wrote:
>>>>>>>
>>>>>>> 2017-09-25 19:19 GMT+02:00, John Mercouris <jmercouris at gmail.com
>>>>>>> <mailto:jmercouris at gmail.com>>:
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20170926/0cabb88d/attachment-0001.html>
More information about the ecl-devel
mailing list