Bug 502434 - org.kde.Sdk: Probable missmatch in provided stdlibs
Summary: org.kde.Sdk: Probable missmatch in provided stdlibs
Status: RESOLVED NOT A BUG
Alias: None
Product: Qt/KDE Flatpak Runtime
Classification: Developer tools
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Flatpak Linux
: NOR normal
Target Milestone: ---
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-05 03:47 UTC by Allan
Modified: 2025-04-25 08:04 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan 2025-04-05 03:47:17 UTC
SUMMARY

I'm not really sure if here is the place to report it, but here I go :

Noticed when using QtCreator from Flatpak, it seems to depend on _org.kde.Sdk_ :
```sh
echo -e '#include <mutex> \n #include <thread> \n #include <memory> \n #include <iostream> \n  int main(){ auto i = std::make_unique<int>(42); std::cout << i << " " << *i << std::endl ; auto t = std::thread([]{}); t.join(); std::mutex m = {}; return 0 ; }' | /var/lib/flatpak/runtime/org.kde.Sdk/x86_64/*/*/files/bin/c++ -std=c++20 -isystem /var/lib/flatpak/runtime/org.kde.Sdk/x86_64/*/*/files/include -x c++ -  && ./a.outIn file included from /var/lib/flatpak/runtime/org.kde.Sdk/x86_64/6.8/2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f/files/include/c++/14.2.0/x86_64-unknown-linux-gnu/bits/gthr-default.h:35,
                 from /var/lib/flatpak/runtime/org.kde.Sdk/x86_64/6.8/2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f/files/include/c++/14.2.0/x86_64-unknown-linux-gnu/bits/gthr.h:157,
                 from /var/lib/flatpak/runtime/org.kde.Sdk/x86_64/6.8/2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f/files/include/c++/14.2.0/bits/std_mutex.h:41,
                 from /var/lib/flatpak/runtime/org.kde.Sdk/x86_64/6.8/2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f/files/include/c++/14.2.0/mutex:47,
                 from <stdin>:1:
/var/lib/flatpak/runtime/org.kde.Sdk/x86_64/6.8/2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f/files/include/c++/14.2.0/bits/std_mutex.h:206:32: error: cannot convert ‘<brace-enclosed initializer list>’ to ‘unsigned int’ in initialization
  206 |     __gthread_cond_t _M_cond = __GTHREAD_COND_INIT;
      |                                ^~~~~~~~~~~~~~~~~~~
/var/lib/flatpak/runtime/org.kde.Sdk/x86_64/6.8/2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f/files/include/c++/14.2.0/ext/concurrence.h:252:32: error: cannot convert ‘<brace-enclosed initializer list>’ to ‘unsigned int’ in initialization
  252 |     __gthread_cond_t _M_cond = __GTHREAD_COND_INIT;
      |                                ^~~~~~~~~~~~~~~~~~~
```
- The error already contains a reproducible test.
-  It completely breaks any Qt compilation.
-  It pretty much seems to be a mismatch between a header and its library. Probably `pthread.h` or `mutex.h`.
    - Not confirmed yet, as I'd have to do lots of testings.
        - And it took me some time debugging my entire application before reaching this "simple" conclusion.
         - And before doing it I'd like to know if it is already tracked.
             - I can, but I'd like to hear about it first.

STEPS TO REPRODUCE
1. Flatpak install `org.kde.Sdk`.
    - I probably got it as a dependency of `io.qt.QtCreator`, not sure since I have lots of _snaps_ and _flatpaks_.
2.  Copy and paste the one-liner in SUMMARY section.
    - Valid tests with `-std=c++20` and `-std=c++23`
    - Earlier standards wouldn't even compile, but for other reasons.
        - `error: no type named ‘type’ in ‘struct std::enable_if<false, void>’`

OBSERVED RESULT
- Thread related operations can't be compiled due to mismatching type and initialization **in standard libraries**.
- As described in summary, it pretty much seems to be a mismatch between headers or header & library.
    - After testing many times, it may also be something wrong with the compiler itself, still need more digging into the problem.

EXPECTED RESULT
- That standard libraries should work when dealing with thread-related calls.
- **It compiles without a problem on system's GCC that is at the same exact version (14.2.0)**
    ```sh
    echo -e '#include <mutex> \n #include <thread> \n #include <memory> \n #include <iostream> \n  int main(){ auto i = std::make_unique<int>(42); std::cout << i << " " << *i << std::endl ; auto t = std::thread([]{}); t.join(); std::mutex m = {}; return 0 ; }' | c++ -std=c++20 -x c++ -  && ./a.out
    0x5642e09c42b0 42
    ```

SOFTWARE/OS VERSIONS
Flatpak @ Linux : Flatpak 1.16.0, Debian testing (trixie) 6.12.20-amd64
GCC inside flatpak : 14.2.0
GCC from system : (Debian 14.2.0-19) 14.2.0
Qt Version: **Flatpak** io.qt.QtCreator 16.0.0 eb00007daed9426ac86c57556aa171f9d6459b2b53e7d7eb352dcc73e9757a4f
KDE SDK Version : **Flatpak** org.kde.Sdk 6.8 2b27c8d886fd7c262f2cf1d4e216eadb5c141cba5a5673afd629b8ab1e5ecf7f

ADDITIONAL INFORMATION
- I've just created a container from scratch, and it occurs as described.
- `-isystem` is optional **for the test**, but required to compile Qt apps.
    - The error will occur without it, but later for a Qt compilation it would be required.
Comment 1 Ardith Metz 2025-04-06 15:14:07 UTC
Looks like you are running this test command directly on host system outside flatpak environment. If you want to test flatpak you need to launch it first - either from desktop file or by opening shell inside through:

flatpak run --command=sh io.qt.QtCreator

Then you may test any relevant commands.
Comment 2 Allan 2025-04-07 12:29:52 UTC
Cool, I didn’t know about this kind of virtual environment—even /tmp behaves differently in it. Very nice! Thanks for pointing out this detail.

I tried it, and it compiled the simple program by replacing the prefix with /usr inside Flatpak’s environment.

Then I started investigating what could’ve been causing the compilation problems in my project, until I realized it was due to the inclusion of Boost, which had been installed via apt. Its headers reside in the same directory as the system's (/usr/include). So the problem isn’t Boost itself, but rather the system libraries and headers located there.

I also noticed that Flatpak’s libc is version 2.40, while the system’s is 2.41. It would be nice if they matched, but now it seems I’ll be quite limited and may have to go back to using Qt the old way, without Flatpak—something I was trying to avoid to keep the system clean.

Before closing it, is there something that I could try? Perhaps locking the same libc?
Comment 3 Bug Janitor Service 2025-04-22 03:47:29 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Allan 2025-04-25 02:46:36 UTC
Well, I think that I've messed up with the Status of the report.

Not sure on what status to put this on.
Comment 5 Albert Astals Cid 2025-04-25 08:04:16 UTC
The status is that what you are doing is not supported so this is not a bug. Using things installed in flatpak without being in the flatpak environment will not work.