Fritzing 1.0.7 is now available, featuring native Apple Silicon support, a Qt framework upgrade to 6.8.3, performance improvements, and many bug fixes.
Highlights
Native Apple Silicon: macOS builds now run natively on M1–M5 Macs without Rosetta
Qt 6.8.3 upgrade: Major framework update with improved rendering and platform support
Faster loading: Part icons loaded from database with caching for quicker startup
300+ Adafruit parts added to the parts library
Copper fill fixed: Ground fill and copper fill work reliably again
Trace routing fix: Multiple traces no longer incorrectly treated as one
Parts Editor fix: “Close without saving” and “Keep working” buttons now work correctly
Gerber export fix: Duplicate aperture in contour files resolved
User parts organized in subfolders by module ID, improving portability
Obsolete parts hidden from swap combobox
Updated translations for 6 languages
Various crash fixes and stability improvements
OS Requirements
macOS: Sonoma or later (Apple Silicon + Intel)
Windows: Windows 10 64-bit or later
Linux: glibc 2.35+ (Ubuntu 22.04 or later)
Downloads
Your purchase supports ongoing development. Recent buyers get this update at no extra cost.
Where is the source code for 1.0.7? The github repo only seems to be for 0.9-ish. I am running on a RPi 5 (aarch64), so I can’t use the x86_64 appimage. I need to build from source.
marchhare% qmake6
Project ERROR: Use at least Qt version 6.5.3
marchhare% qmake6 --version
QMake version 3.1
Using Qt version 6.4.2 in /usr/lib/aarch64-linux-gnu
marchhare% git branch
1.0.3
* 1.0.7
develop
From the message, the build needs a newer version of QT than you currently have installed on your system. You could try updating that then attempt the build again. Or set up to use parallel version, and configure to use one that works. The method to do the update varies by linux distro.
If you want to build an application from source, you must be willing to get all of the dependencies as well.
It is not clear what you mean by “upgrade my Linux system”. QT does not need a system upgrade. My memory, from maybe ten years ago, says that to build with QT, you need a folder full of library code. Each QT version is a different folder. All can exist at once. You just need to point the build to the correct folder for the version to be used.
For ARM64 AppImage, not that I am aware of. I am not associated with the build team.
An official build for Raspberry Pi5 and similar (aarch64) is on our todo. Apple silicon had priority before that, and wascfinally added with 1.07. Since that now seems to work smoothly, i should find time to add another target.
Rebuilding a separate version of QT might add its own problems. It might have dependencies that would need to be satisified. I don’t use Fritizing enough to really justify the level of effort needed. The version in the Debian bookworm repository (0.9.6+dfsg-3) does work well enough. I was mostly curious if 1.0.7 managed to “fix” any of the issues I continue to have with 0.9.6. But it is not worth the extra effort of dealing with the dependencies involved.
Yep. building QT 5.6.2 on my Raspbian 12 system is not working. I’m guessing I need a newer version of libssl… It is looking like a case of dependency hell…
I think it will be an AppImage. I have a Pi5 4GB, which is a bit weak to build Fritzing continuously, and is probably quite difficult to build Qt on. Apple Silicon + Ubuntu VM seems more workable, the Pi5 would just be used for smoke tests.
Ubuntu 22 → glibc 2.35. If I am correct, bookworm is on glibc 2.36, so the AppImage will run there as well.
I use a RPi 5 w/ 4Gig as my main desktop. I works quite well, except when I open too many tabs in Firefox and exhaust virtual memory (RAM+SWAP). (Firefox is always “expendable”.)
marchhare% dpkg-query -l libc6|grep ^ii
ii libc6:arm64 2.36-9+rpt2+deb12u14 arm64 GNU C Library: Shared libraries
ii libc6:armhf 2.36-9+rpt2+deb12u14 armhf GNU C Library: Shared libraries
It is beginning to look like building a newer version of QT on my Rasbian 12 system is not going to work. I will probably has to wait for the AppImage build or upgrade my whole system to Rasbian 13 (which is what I feared originally).
In theory yes, but it gets more difficult with dependencies. Back (or foward) porting Fritzing would mean to maintain a second set of versions. So the dependencies would also need to be cross compiled, and it would still leave the deployment open (not yet an Appimage, even if it runs locally) . A native build doesn’t have all that problems. We have Arm64 in our zoo of machines anyway, eg for testing Windows ARM and the universal binary on macos.
In my case I don’t have any other environments. The only x86_64 machine I have is an old (2012 vintage) MacBook… And compiling QT 5.6.2 on Raspbian 12 is getting to be a pretty much lost cause – there is at least one broken Makefile. I’ll probably stick with Fritzing 0.9.6 until such time as I upgrade to Raspbian 13, which will likely mean I might end up with Fritzing 1.0.1.
OK, I finally got Qt 5.6.3 built successfully. But I get this error trying to build fritzing:
marchhare% ~/qt-everywhere-opensource-src-5.6.3/BUILD/qtbase/bin/qmake ..
/home/heller/fritzing-app/phoenix.pro:23: 'versionAtLeast' is not a recognized test function.
Project ERROR: Use at least Qt version 6.5.3
marchhare% git branch
* 1.0.7
develop
marchhare% ~/qt-everywhere-opensource-src-5.6.3/BUILD/qtbase/bin/qmake -v
QMake version 3.0
Using Qt version 5.6.3 in /home/heller/qt-everywhere-opensource-src-5.6.3/BUILD/qtbase/lib
marchhare% dir
marchhare% pwd
/home/heller/fritzing-app/BUILD
Working just from the messages, qmake is accessing a configuration (or makefile) that includes a reference to “versionAtLeast”, and that version of qmake does not recognize it. Might in a code segment someplace since that says “not a recognized test function”. If it was a command line argument, I would expect different wording. You might try the original command line, and add a “verbose” type command option (I do not have the available qmake flags handy, but often “–verbose” or “–VV”).
