Nuitka: FileDialog PyQt5>K error
Factory Nuitka as requested: 1.9rc6 Commercial: None Python: 3.8.10 (default, Oct 4 2023, 11:36:56) Flavor: Unknown Executable: /home/daniel/Desktop/nuitka_tests/env/bin/python OS: Linux Arch: x86_64 Distribution: Ubuntu (based on Debian) 18.04.6 Version C compiler: /usr/bin/gcc (gcc).
Python3.8.10 from source with, only enabled optimizations, created a new venv from it and then pulled factory from pip
python -m pip freeze:
Nuitka @ https://github.com/Nuitka/Nuitka/archive/factory.zip
ordered-set==4.1.0
PyQt5==5.15.6
PyQt5-Qt5==5.15.2
PyQt5-sip==12.13.0
zstandard==0.21.0
Breaking sample code:
import sys
from PyQt5.QtWidgets import QApplication, QMainWindow, QPushButton, QFileDialog
class FileDialogExample(QMainWindow):
def __init__(self):
super().__init__()
self.initUI()
def initUI(self):
self.setGeometry(100, 100, 400, 200)
self.setWindowTitle('File Dialog Example')
self.button = QPushButton('Open File Dialog', self)
self.button.setGeometry(150, 80, 150, 30)
self.button.clicked.connect(self.showFileDialog)
def showFileDialog(self):
options = QFileDialog.Options()
options |= QFileDialog.ReadOnly
file_dialog = QFileDialog()
file_name, _ = file_dialog.getOpenFileName(self, 'Open File', '', 'All Files (*);;Text Files (*.txt);;Python Files (*.py)', options=options)
if file_name:
print(f'Selected File: {file_name}')
def main():
app = QApplication(sys.argv)
ex = FileDialogExample()
ex.show()
sys.exit(app.exec_())
if __name__ == '__main__':
main()
- Provide in your issue the Nuitka options used
Built with:
python -m nuitka --standalone --enable-plugin=pyqt5 --report=compilation-report.xml pyqt5_file_dialog.py
This code is built on Ubuntu 18.04 and works from the *.dist build folder on the same system: On moving to an Ubuntu 22.04 system and trying to run the same way I get the following issue as described. When clicking the file dialog button:
...
...
...
Fontconfig error: "/etc/fonts/conf.d/80-delicious.conf", line 5: invalid attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/80-delicious.conf", line 6: invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/80-delicious.conf", line 6: invalid attribute 'version'
Fontconfig warning: "/etc/fonts/conf.d/90-synthetic.conf", line 4: unknown element "its:rules"
Fontconfig warning: "/etc/fonts/conf.d/90-synthetic.conf", line 5: unknown element "its:translateRule"
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 5: invalid attribute 'translate'
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 5: invalid attribute 'selector'
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 6: invalid attribute 'xmlns:its'
Fontconfig error: "/etc/fonts/conf.d/90-synthetic.conf", line 6: invalid attribute 'version'
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
(main.bin:21344): Gtk-WARNING **: 13:54:50.175: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
GTK is not being explicitly installed by pip as shown on the venv freeze and I’m not trying to use GTK for anything. I won’t attach the build xml but it was shared by email if useful. Just posting here if the code or reference is helpful. Thanks
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 18 (14 by maintainers)
Hi @kayhayen, I tested this ticket’s sample code and I can confirm it’s working now 😃
I believe now would be a good time to test this, I am intent on making a 1.9 release as soon as possible, just doing a bit of house keeping.
I just managed to compile on Ubuntu 18.04 run it on Fedora 38, using Debian Python (which should be kind of worst case) with no single warning, and it saving the image. I will strive to make it clean now.
I feel like “package name” attached to DLLs is not really enough, modules should be allowed to be tracked for DLLs too, which would be a bigger change, but for now, the new default would apply to all packages, and to no global namespace extension module, which is kind of unacceptable. The package name is currently used to decided extended DLL search paths for used DLLs of a package, e.g. PySide6 also searching in shiboken6, but not globally of course. But in order to decide stdlib DLL, we need to know the module name a DLL came from. This is mostly a cleanup, and I will have a report file to compare to to see if it is still remaining as good.
So, I managed to implement this, but it now is a too aggressive, and does the same for stdlib, which wouldn’t be a problem, but reveals that
sys.prefixis needed to be considered an inside path too. Still refining, but it seems were are getting there.So, diffing the compilation report shows that we got the desired effects, in terms of DLL inclusion. I saw a shift for some DLLs from
PyQt5Qt plugin usage as a reason for a DLL tocv2orglfwusage. Those are not good, and I think I shall first change that PyQt/PySide plugin code, to becoming per package decisions, where we will have to be dealing with sub-packages, etc. properly. as well.This feels easy now, hopefully, I can manage that a lot quicker. And I suspect, there is going to be a bunch of fallout from the new package scan requirements, but we can achieve wide working relatively quickly.
I do not consider that the specific package versions play a role at all at this time, so stick to what you have, no problem. This is a very general issue probably. As for the 3.11 issue, that’s one where people complain that
os.__file__gets lost or isn’t set, and I meant that just for priority, that’s critical for me today too, doesn’t seem this is affected at all, or for that to be a generally impactful issue.