Hi,

I opened the following question on Stack Overflow:
https://stackoverflow.com/questions/527 ... -container

To summarize, the QDir::exists() method does not work in the kdeneon docker image.

With the latest tests (see my last comment), it seems that the problem comes from the kdeneon docker image from Docker hub (the problem does not occur in my KDE Neon host nor in a ubuntu:18.04 docker image).

Any idea of the possible origin of the problem ?

Gaël

Since 5.10 Qt is using somewhat new syscalls. One of them is statx and last I checked the syscall was not whitelisted in docker, nor was it whitelistable because the libseccomp used for the upstream docker build was too old and didn't know what statx is. Chances are the problem you see is that. If so, seccomp=unconfined would make it work.

apachelogger wrote:Since 5.10 Qt is using somewhat new syscalls. One of them is statx and last I checked the syscall was not whitelisted in docker, nor was it whitelistable because the libseccomp used for the upstream docker build was too old and didn't know what statx is. Chances are the problem you see is that. If so, seccomp=unconfined would make it work.

You are probably right. Thank you. Passing seccomp=unconfined made it work as suggested.
Can I copy your answer to stackoverflow ?

Gaël

Sure

apachelogger wrote:Since 5.10 Qt is using somewhat new syscalls. One of them is statx and last I checked the syscall was not whitelisted in docker, nor was it whitelistable because the libseccomp used for the upstream docker build was too old and didn't know what statx is. Chances are the problem you see is that. If so, seccomp=unconfined would make it work.

@apachelogger, a (maybe) complementary question: when I build and execute the Qt program on a kdeneon docker image on a KDE Neon host, it works as expected (with the problem above), but when I build and execute it on a docker image on a Debian 8 host, it fails with

Code: Select all

liqQt5Core.so.5: cannot open shared object file: No such file or directory

, while the lib obviously exist. Could it be again related to incompatible system calls? Or should I search (and ask) elsewhere?

Unlikely, certainly not if you disable seccomp. It's probably best to strace it and see what's going on, maybe the library lookup paths are wrong.

apachelogger wrote:Unlikely, certainly not if you disable seccomp. It's probably best to strace it and see what's going on, maybe the library lookup paths are wrong.

OK. Thanks. I'll see if I find time to trace the problem. But the simplest solution will be to switch to a newer OS on the host which was scheduled anyway.