ECL + EQL Standalone Binary
Joshua Kordani
jkordani at lsa2.com
Tue Sep 26 17:56:38 UTC 2017
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/69c621d7/attachment-0001.html>
More information about the ecl-devel
mailing list