ECL + EQL Standalone Binary

Tue Sep 26 15:15:40 UTC 2017

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> wrote:
> 
> 2017-09-25 19:19 GMT+02:00, John Mercouris <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/4f4956e8/attachment.html>