Alright, so the quick follow up:

The problem is that you try to cross-compile ECL with an older version of the compiler. First you need to build the same version for your host system and then use it to cross compile. Symbols in the table doesn't match. When you do that use:

rm -rf build/ ./configure --host=arm-linux-gnueabi # now edit file build/cross_config (set ECL_TO_RUN variable)

and all should work fine. If your toolchain doesn't have atomic_ops library then build may have some problems if you need them. In that case either use different flags or install said library.

Best regards, Daniel

First of all, sorry for the horrible formatting of my initial e- mail. I'm using a proper mail program now.

Secondly, thanks for the reply and apologies for the late reply: the year turnaround got in the way.

No worries, I figured that much :-).

"Daniel Kochmański" wrote on Sunday, 2018-12-30 20:56:

...

Alright, so the quick follow up:

The problem is that you try to cross-compile ECL with an older version

[…]

...

and all should work fine. If your toolchain doesn't have atomic_ops library then build may have some problems if you need them. In that case either use different flags or install said library.

Hm, I did compile the same ECL for the host before making this report since that was mentioned in the README (or INSTALL) but it didn't seem to make a difference. So I will try your above suggestion. Never thought of this since I'm not very familiar with with the atomic_ops stuff.

but did you "make install" the host ECL, remove build/ directory, configure for cross compilation (once), customize ECL_TO_RUN in build/cross_config directory and run configure and make after that? Your error really looks like your build has picked some older ECL version (i.e from /usr/bin/ecl if you have ECL installed from the repositories).

As you wrote in your earlier reply about compiling on the machine itself: I wanted to avoid this since the Sailfish SDK offers both an emulator (x86) and a way to deply directly on the machine (ARM), but on further thought I might just go for this option. It might actually make things easier instead of more difficult (which I initially thought).

Native compilation is always the most certain way get things working. In any case when you succeed (or fail!) please let us know what you did.

Best regards (and a Happy New Year!), Daniel

Congrats! Please send me photos of the phone running ECL, I'll brag about it on social media ;-)

So, to follow up on this I've gotten ECL running on the SailfishOS emulator. In the end (after finding the right web page) it was pretty easy to get shell access to the emulator and run `./configure`, `make` and `make install` there. Although it's a cross-compilation environment it worked without an issue.

Now on the EQL! (SailfishOS runs QT (but with their own layer on top of it :-( ).)

And then try to get it running on the actual phone...

Thanks again, Erik

On 2019-02-17 08:43, Renaud Casenave-Péré wrote:

I am the one who packaged ecl for salifish and put it on openrepos.net. As per my light testing it is working fine, together with EQL5 which I also packaged.

Oh great, thanks for replying!

If you have questions for me, don’t hesitate.

I got sidetracked by work and family but I want to pick this up again in the near future. So, I can see how I would use ECL together with QML to write apps for SailfishOS, but I'm unclear how EQL fits in here due to Sailfish's own layer on top of QT (Silica).

Perhaps this will become clear to me once I start working with this again.

Regards, Erik

Hi,

On Mon, Feb 18 2019, PR wrote:

2019-02-18 12:10 GMT+01:00, Erik Winkels aerique@xs4all.nl:

...

...but I'm unclear how EQL fits in here due to Sailfish's own layer on top of QT (Silica).

That's not a problem: Silica is written in QML, in order to provide custom look and feel for Sailfish, so you only need to import Silica at the top of your QML files like this:

import Sailfish.Silica 1.0

(Not that I have any experience with Sailfish/Silica, just repeating what the docu says.)

That’s pretty much about it. I would also suggest to create the Qt application in C++ using functions from libsailfishapp (https://github.com/sailfishos/libsailfishapp) to speed up a bit the application launch but it is not mandatory.

The approach I’m experimenting right now is a mix of “my_app” and “M-modules/quick” examples from EQL5 and it seems to be a viable one.

I stumbled upon a crash at launch (floating point exception) when trying to run something ecl/eql related in the emulator but it is working fine on the device.

I still need to find a way to efficiently use slime with this setup.

I might put a template on a public repository to help quickstart application development when I’m satisfied with my environment.

On 11/8/19, Erik Winkels aerique@xs4all.nl wrote:

Have you been able to "import EQL5 1.0" the quick module?

just a generic note: as soon as you load the quick module from Lisp using: (eql:qrequire :quick) the EQL5 1.0 module is available in QML.

If you are using Qt Creator to edit QML (surely the preferred way), it will tell you: import EQL5 1.0 "QML module not found (EQL5)." as a red warning message; but this can simply be ignored.

(Don't know if this is helpful in your situation.)

Paul

Hi all,

Sorry for being silent on this for almost a year, but I've been switching between phones, SailfishOS (SFOS), GrapheneOS and LineageOS a lot. Trying to find something that would fit my combination of preferences (the hardest two being combining SFOS and a good camera). That, and corona.

On 2019-11-16 09:06, Renaud Casenave-Péré wrote:

Yes, I haven’t had any issues. Lisp.call() in qml files works as it should. Paul’s advice might be what you are looking for.

You can have a look at my eql5-sfos sample repository. It compiles the C++ file and all lisp files, and deploy a package, all from within Qt Creator. I am working with the application deployed directly on the phone but I don’t see why it would be different in the emulator.

I just finished doing this directly on the phone and it works for me and I've also been able to use Lisp.call() from QML successfully, so thanks!

The app is a little sluggy because I installed `wayland-egl` and `mesa-llvmpipe-dri-swrast-driver` to get it running. I'm sure I'm doing something wrong here, but for now I'm happy!

Regards, Erik

Hi Rene,

I got sidetracked by work and family life, but I started playing with this again yesterday:

On 2019-02-17 08:43, Renaud Casenave-Péré wrote:

I am the one who packaged ecl for salifish and put it on openrepos.net. As per my light testing it is working fine, together with EQL5 which I also packaged.

Do you have any hints for on how you got EQL5 packaged? I've got building ECL down to repeatable steps but with EQL5 I run into issues with:

- `printsupport` and `uitools` in the .pro files - `#include <QtPrintSupport>` in a lot of generated header files - `#include <QUiLoader>` in one header file

Thanks, Erik

Hi Erik,

Thank you for poking me, Like you I haven’t taken the time to continue on this project since last time…

• `printsupport` and `uitools` in the .pro files
• `#include <QtPrintSupport>` in a lot of generated header files
• `#include <QUiLoader>` in one header file

Yes, for those you just have to install missing packages. I also had to remove manually 5 classes that were part of libraries not found in sailfish distribution. Those are:

From QMultimediaWidgets:

- QCameraViewfinder - QGraphicsVideoItem - QVideoWidget - QVideoWidgetControl

From QtQuickWidgets:

- QQuickWidget

For references, I have a private repository with some changes of mine to make it work. I noticed it’s not up-to-date with upstream, so expect things to change quite a bit when I find the time to make another package. Of course, comments are welcome:

https://redmine.casenave.fr/sfos/eql5.git

I also made a repository for the rpm spec file I used to make the package for sailfish:

https://redmine.casenave.fr/sfos/eql5-spec.git