Fix Windows MSVC build: quazip path typo, missing system/zlib libs - #4331
Open
codemee wants to merge 1 commit into
Open
Fix Windows MSVC build: quazip path typo, missing system/zlib libs#4331codemee wants to merge 1 commit into
codemee wants to merge 1 commit into
Conversation
quazipdetect.pri appended a stray "intuisphere" suffix onto QUAZIP_PATH, so qmake could never find a correctly-named quazip folder on any platform. On win32, libgit2 (built as a static lib against WinHTTP/CryptoAPI) needs winhttp, rpcrt4, crypt32, ole32, secur32, ws2_32 and advapi32 to resolve symbols like WinHttpOpen, CryptAcquireContextA and RegOpenKeyExW at link time, none of which qmake pulls in by default. QuaZip's gzip file support (QuaGzipFile) also needs zlib's gz* API (gzopen/gzread/gzwrite/...), which isn't exported by Qt's bundled/ private zlib, so the final Fritzing.exe link fails with unresolved externals unless a real zlib library is linked in on win32. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
While building Fritzing from source on Windows (Qt 6.10.3, MSVC 2022, x64), I ran into two build-breaking issues in the qmake
pri/files:pri/quazipdetect.priappends a strayintuispheresuffix ontoQUAZIP_PATH, so qmake looks for a folder likequazip-6.10.3-1.4intuisphereinstead ofquazip-6.10.3-1.4, and always fails with"quazip could not be found at ...".win32, the link step fails with unresolved externals:git2.lib:WinHttpOpen,RegOpenKeyExW,CryptAcquireContextA, etc. — libgit2 (built as a static lib with the WinHTTP backend) needswinhttp,rpcrt4,crypt32,ole32,secur32,ws2_32,advapi32, none of whichpri/libgit2detect.prilinks on Windows.quazip1-qt6.lib:gzopen,gzread,gzwrite, etc. —QuaGzipFileneeds zlib's gzip-file API, which isn't exported by Qt's bundled/private zlib. A real zlib build needs to be linked on win32 (I built zlib 1.3.1 from source and placed it as a siblingzlib-1.3.1folder, matching this project's existing convention forlibgit2-*/quazip-*/Clipper1-*).With both fixes,
qmake && jomproduces a workingFritzing.exeon Windows 10/11 x64, and I've verified it launches correctly and loads the parts library.Test plan
qmake phoenix.prosucceeds and finds quazip at the correct pathjom -f Makefile.Releasecompiles and linksFritzing.exewithout unresolved externalsFritzing.exe, confirmed the Parts panel and Inspector load real parts from a freshly generatedparts.dbCo-Authored-By: Claude Sonnet 5 noreply@anthropic.com