This list is also fine.

Best regards, DK

-------- Oryginalna wiadomość -------- ‎ 9 gru 2020, 09:17, PR napisał(a):

On 12/6/20, Erik Winkels aerique@xs4all.nl wrote:

...

I know little of QT however and looking at the EQL5 examples only gets me so far. What would be a good venue to ask my (initially really basic) questions on the combination of ECL, EQL and QT? I mean, I want to ask questions to people who also like to program in Common Lisp so I don't have to have a discussion thread first on why I am not using C++ or Python.

There is now a web logged #eql5 IRC channel, that would be the perfect place. The (searchable) logs can be found here:

https://irclog.tymoon.eu/freenode/%23eql5

For now it's empty, you're welcome to fill it with some content :) And for people not running an IRC client all day long, there are also web clients, like this one:

https://webchat.freenode.net/

Paul

Hey,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, March 1, 2021 1:54 PM, Renaud Casenave-Péré renaud@casenave-pere.fr wrote:

I am also a bit concerned about asking end-users to add an unrelated repository to be able to install your applications and I was wondering if there is a possibility to statically link against libecl and libeql5. That way applications could be truly standalone and maybe even acceptable for the jolla shop.

when you specify --disable-shared during configuration, then ecl will be compiled statically (one of the artifacts will be named libecl.a). This solution has a drawback, because you won't be able to load .fas files at runtime (but .fasc are fine). In the future, it would be nice to separate these two things with different flags.

Best regards, Daniel

Hello,

On 01-03-2021 13:54 Renaud Casenave-Péré renaud@casenave-pere.fr wrote:

In that regard I have prepared a package for the latest ecl release (21.2.1) but you’ll have to recompile and reupload your applications using the newest libraries when I update my repository. I’m not sure how storeman behave regarding broken dependencies.

I think I could pin my apps to specific versions in the RPM spec but don't have much experience with packaging and I haven't tried it yet.

I don't know if you have the time, but I would be very interested in having 64-bit versions as well.

Could you give me a heads-up when you've uploaded the 21.2.1 release?

I am also a bit concerned about asking end-users to add an unrelated repository to be able to install your applications

It's common for packages on OpenRepos to ask this. OpenRepos is for more experienced users and they should be able to do this. (Yes, this is a bit of a cop-out.)

I was wondering if there is a possibility to statically link against libecl and libeql5. That way applications could be truly standalone and maybe even acceptable for the jolla shop.

That would be very cool, and I see Daniel has answered to this already.

Bye, Erik

Hi,

I don't know if you have the time, but I would be very interested in having 64-bit versions as well. Could you give me a heads-up when you've uploaded the 21.2.1 release?

Packages have been uploaded, together with an aarch64 version. Same for eql5. No static libraries yet,though.

Cheers,

On Tuesday, April 27, 2021 1:13 PM, Erik Winkels aerique@xs4all.nl wrote:

$ eql5-sfos [D] unknown:0 - Using Wayland-EGL

Condition of type: SIMPLE-ERROR Package ((SB-BSD-SOCKETS . #<SB-BSD-SOCKETS package>)) referenced in compiled file

  NIL
but has not been created

Just a quick reply: with a static build, you need to statically link all of the (eventually needed) dependencies of the ECL 'contrib' libs into your executable. Please see the following line of an iOS example, where the 'sockets' lib (needed in your case) is added manually as a static lib dependency:

https://gitlab.com/eql/eql5-ios/-/blob/master/examples/REPL/repl.pro#L7

(note -lsockets)

Paul

Hi,

On 28-04-2021 22:27 pls.153 pls.153@protonmail.com wrote:

Just a quick reply: with a static build, you need to statically link all of the (eventually needed) dependencies of the ECL 'contrib' libs into your executable. Please see the following line of an iOS example, where the 'sockets' lib (needed in your case) is added manually as a static lib dependency:

Thanks, so it looks like this is what Rene meant with "No static libraries yet,though." in his earlier e-mail.

I'll wait for a while, since I was just playing around.

Erik

Hi,

On 29-04-2021 13:50 Renaud Casenave-Péré renaud@casenave-pere.fr wrote:

Actually I was referring to an earlier release. The currently released packages are considered fully working. Paul’s solution is the way to go.

[...]

Could you try with Paul’s solution and report back if it works for you or not?

I had tried Paul's solution but it didn't work for me. Now that you said it should actually work I tried again and I did also see where I did go wrong on my earlier attempt.

So, after adding Drakma as dependency to Renaud's `eql5-sfos` I ran into the issue I mailed about earlier. After trying Paul's solution by adding this to the `eql5-sfos.pro` file:

- `LIBS += -L/usr/lib/ecl-21.2.1 -l:libasdf.a -l:libsockets.a`

And doing this in `src/eql5-sfos.cc`:

- `ecl_init_module (NULL, init_lib_ASDF);` - `ecl_init_module (NULL, init_lib_SOCKETS);`

It gets me past the `SB-BSD-SOCKETS` and `UIOP/OS` errors, but now I get the following error:

$ eql5-sfos [D] unknown:0 - Using Wayland-EGL

Condition of type: FILE-ERROR Filesystem error with pathname "SYS:help.doc". Either 1) the file does not exist, or 2) we are not allowed to access the file, or 3) the pathname points to a broken symbolic link. No restarts available.

Top level in: #<process TOP-LEVEL 0xb0581fc0>.

Which is at least different :-)

I tried including `help.doc` as a dist file in `eql5-sfos.pro` but that didn't work and I guess there's more to solving it than that. (Perhaps something to do with `libecl-help.a`?)

Thanks so far, Erik

Le 29/04/2021 à 17:25, pls.153 a écrit :

On Thursday, April 29, 2021 4:31 PM, Erik Winkels aerique@xs4all.nl wrote:

...

 Condition of type: FILE-ERROR
 Filesystem error with pathname "SYS:help.doc".
 Either
 1.  the file does not exist, or
 2.  we are not allowed to access the file, or
 3.  the pathname points to a broken symbolic link.
     No restarts available.

     Top level in: #<process TOP-LEVEL 0xb0581fc0>.

I had the same issue on iOS, here is what I did:

;; needed e.g. for loading 'help.doc' (setf (logical-pathname-translations "SYS") (list (list #p"sys:**;*.*" (merge-pathnames "**/*.*" (user-homedir-pathname)))))

Now you can put "help.doc" in (user-homedir-pathname), and ECL will find it.

It's not prudent to use #P in the logical-pathname-translations. This is because #P is a read-time reader macro: it calls PATHNAME at read-time, before the logical-pathname-translations may be set, ie. potentially before the logical host is created. Therefore it will fail.

For a time, I just created the logical hosts with

(setf (logical-pathname-translations "SYS") '()) ; creation of the logical host (setf (logical-pathname-translations "SYS") (list (list #p"sys:**;*.*" (merge-pathnames "**/*.*" (user-homedir-pathname)))))

but in fact, we may just use namestrings:

(setf (logical-pathname-translations "SYS") (list (list "SYS:**;*.*" (merge-pathnames "**/*.*" (user-homedir-pathname)))))

Hi again,

On 29-04-2021 17:49 pls.153 pls.153@protonmail.com wrote: On Thursday, April 29, 2021 5:31 PM, Pascal Bourguignon pjb@informatimago.com wrote:

...

but in fact, we may just use namestrings:

(setf (logical-pathname-translations "SYS") (list (list "SYS:;." (merge-pathnames "/."(user-homedir-pathname)))))

thanks for the hint,

Thanks to you guys I made some more steps.

Currently (but I have not investigated it further since I'm stopping for tonight) I'm stuck on loading foreign libs and I hope it is not a blocker because of the statically linking (i.e. is it even possible to load foreign libs?):

$ eql5-sfos [D] unknown:0 - Using Wayland-EGL

Condition of type: LOAD-FOREIGN-LIBRARY-ERROR Unable to load any of the alternatives: ("libssl.so.1.1" "libssl.so.1.0.2m" "libssl.so.1.0.2k" "libssl.so.1.0.2" "libssl.so.1.0.1l" "libssl.so.1.0.1j" "libssl.so.1.0.1f" "libssl.so.1.0.1e" "libssl.so.1.0.1" "libssl.so.1.0.0q" "libssl.so.1.0.0" "libssl.so.0.9.8ze" "libssl.so.0.9.8" "libssl.so.10" "libssl.so.4" "libssl.so") Available restarts:

1. (RETRY) Try loading the foreign library again. 2. (USE-VALUE) Use another library instead.

Top level in: #<process TOP-LEVEL 0xb4dedfc0>.

Like I said, I have not dived into this yet so feel free to ignore this.

Thanks again, Erik

On Thursday, April 29, 2021 9:48 PM, Erik Winkels aerique@xs4all.nl wrote:

Condition of type: LOAD-FOREIGN-LIBRARY-ERROR Unable to load any of the alternatives: ("libssl.so.1.1" "libssl.so.1.0.2m" "libssl.so.1.0.2k" "libssl.so.1.0.2" "libssl.so.1.0.1l" "libssl.so.1.0.1j" "libssl.so.1.0.1f" "libssl.so.1.0.1e" "libssl.so.1.0.1" "libssl.so.1.0.0q" "libssl.so.1.0.0" "libssl.so.0.9.8ze" "libssl.so.0.9.8" "libssl.so.10" "libssl.so.4" "libssl.so")

you could try to pre-load them using Qt instead. Just put those lines before loading your EQL code.

I tried the following trivial 'main.cpp' on Sailfish, and it worked for loading the libs:

#include <QCoreApplication> #include <QLibrary> #include <QtDebug>

static bool loadLib(const QString& name) { QLibrary lib(name); bool ok = lib.load(); qDebug() << "loading" << name << ok; return ok; }

int main(int argc, char** argv) { QCoreApplication app(argc, argv);

loadLib("crypto.so.1.1"); loadLib("ssl.so.1.1");

return 0; }

Paul

On 01-05-2021 15:32 Erik Winkels aerique@xs4all.nl wrote:

I think that's enough to attempt the same for my apps tonight.

So when really starting to use Drakma I get OpenSSL errors about not being able to determine the version. Since I'm going on holiday tomorrow I'm going to give it a rest for now.

Thanks for all the help.

On Monday, March 1, 2021 1:54 PM, Renaud Casenave-Péré renaud@casenave-pere.fr wrote:

I also welcome Paul to the sfos community and if you allow me I’ll continue maintaining eql5 package but if you’d rather taking it over just let me know.

Thanks, and yes please continue to maintain the eql5 package!

IMO it would be important to keep the current dynamic packages for developing, and eventually offer static packages (similar to the iOS port) for deployment only.

Paul