Crash when opening Current Drawing Preferences
Version: 2.2.0.2 Compiler: GNU GCC 15.0.1 Compiled on: Jan 17 2025 Qt Version: 5.15.17 Boost Version: 1.83.0 System: Fedora Linux 42 (Workstation Edition)
From the menu choose Options -> Current Drawing Preferences
Expected: The current drawing preferences dialog to open
Actual: *** stack smashing detected ***: terminated Aborted (core dumped)
The Application Preferences dialog opens without issue.
There is more recent version. You can try 2.2.1.1
also, we should be releasing a 2.2.1.2 soon.
I'm currently busy due to some family emergency.
I am having the same issue. Was working up until my fedora 'dnf update' of last week. Ran updates and rebooted again today and it is still crashing.
Version: 2.2.0.2 Compiler: GNU GCC 14.1.1 Compiled on: Jul 18 2024 Qt Version: 5.15.17 Boost Version: 1.83.0 System: Fedora Linux 41 (Workstation Edition)
I found that it works on my laptop which is running the same LibreCAD package on the same OS. Seems like it might be more of a Fedora issue than a LibreCAD issue.
I pulled the source code for 2.2.1.1 and compiled. It does not crash.
Opened a PR to update the package in Fedora. If someone needs a workaround for now, they can pull the RPMs out of the builds linked in the PR. https://src.fedoraproject.org/rpms/librecad/pull-request/3
Bugzilla Issue tracking this https://bugzilla.redhat.com/show_bug.cgi?id=2372635
@dxli This was made more difficult because currently Fedora pulls libdxfrw from https://github.com/LibreCAD/libdxfrw and builds it as a separate package, then patches LibreCAD to use that version. However, that repo does not seem to be maintained consistently as brought up in https://github.com/LibreCAD/libdxfrw/issues/80. So I using the bundled one and marked it as a bundled library. Fedora is not a fan of bundled libraries. Hopefully the package maintainers don't have a problem with that. But it would help if the libdxfrw repo is either kept updated or archived.
Install from flathub 2.2.1.2 version is working correctly!
@avylove
From our side, I'm thinking about a new libdxfrw release to make the upstream more consistent for package maintainers.