Skip to content

fix(build): macOS/Linux builds and make the build process handle its own dependencies#251

Open
yuunalein wants to merge 7 commits into
OpenAEC-Foundation:mainfrom
yuunalein:main
Open

fix(build): macOS/Linux builds and make the build process handle its own dependencies#251
yuunalein wants to merge 7 commits into
OpenAEC-Foundation:mainfrom
yuunalein:main

Conversation

@yuunalein

Copy link
Copy Markdown

I found this project, thought it looked neat, and tried to run it on my Mac. It didn't run. Cloning and building dumped me straight into an app that refused to even start, so I ended up fixing it just to see the thing work at all. The fix turned out to be more than a one-liner, so against my better judgment I cleaned it up properly and I'm sending it as a PR.

There are already several open issues from other people hitting the exact same broken non-Windows builds. I'd rather not toss another ignored bug report onto that pile, so here's the actual fix instead of a complaint.
(#249, #244, #242, ...)

What was broken

  • pdfium.dll was committed straight into src-tauri/binaries/win-x64/ and referenced as a bundle resource. Windows only. Nothing for macOS, nothing for Linux.
  • build.rs just assumed the pdfium-worker binary had already been compiled and staged somewhere by someone else. It tried to copy the file if it happened to exist and otherwise did nothing at all — silently, of course.
  • pdfium-worker only looked for its dynamic library in the current working directory (the Windows way) and nowhere else.
  • target/ wasn't gitignored, so build artefacts were merrily piling up in version control.
  • At runtime, pdfium-worker.exe was looked up by that literal name, unconditionally. On every non-Windows platform the worker pool quietly gave up and fell back to in-process PDFium.
  • And plenty more that I chose to walk past for the sake of my own sanity.

What this PR does

  • Rewrites build.rs so it actually handles its own dependency setup instead of hoping someone did it first. It compiles pdfium-worker via cargo build --message-format json (parsing the output to find the executable), then downloads the correct pdfium release from bblanchon/pdfium-binaries for the current target — libpdfium.so, libpdfium.dylib, or pdfium.dll — with SHA-256 verification. Everything lands in target/runtime-deps/ instead of src-tauri/binaries/.
  • Fixes the dynamic library search paths in pdfium-worker so it looks where the library actually lives on each platform: the app bundle on macOS, and the AppImage or /usr/lib on Linux, instead of blindly checking the working directory like it's still on Windows.
  • Deletes pdfium.dll and binaries/win-x64/ from the repo, and adds target/ to .gitignore where it belonged in the first place.
  • Removes the now-pointless per-platform CI steps that manually built and staged the pdfium-worker sidecar before the Tauri build.
  • Removes the committed binaries/win-x64/pdfium.dll reference from tauri.conf.json bundle resources.
  • Fixes the runtime binary lookup in lib.rs and worker_pool/mod.rs to use pdfium-worker (no extension) on Unix and pdfium-worker.exe on Windows, like it should have from the start.
  • Removes some stray Cargo.lock files from sub-crates.

In the meantime

Until this actually gets merged, I've made a release on my fork with working Linux and macOS downloads, so anyone else who just wants the thing to run doesn't have to go through all of this themselves.

@yuunalein yuunalein requested a review from mojtabakarimi as a code owner July 5, 2026 01:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant