**Severity:** Critical — app will not launch at all on a clean Mac.
**Build affected:** NetDrive 3.19.26 (universal, x86_64+arm64). Likely the same in adjacent 3.19.x builds — please check your full pipeline.
**Reproduction:** Download NetDrive 3.19.26 from bdrive.com, install to /Applications on any Mac that does **not** have Homebrew + `qt@5` installed, double-click. Crash on launch, every time.
## Crash signature
The bundle never makes it past dyld:
```
Termination Reason: Namespace DYLD, Code 1 Library missing
dyld[xxxxx]: Library not loaded:
'@@HOMEBREW_CELLAR@@/qt@5/5.15.18/lib/QtWidgets.framework/Versions/5/QtWidgets'
Referenced from: '/Applications/NetDrive.app/Contents/Frameworks/QtSvg.framework/Versions/5/QtSvg'
Reason: tried: '/System/Library/Frameworks/QtWidgets.framework/Versions/5/QtWidgets' (no such file)
```
The string `@@HOMEBREW_CELLAR@@` is the giveaway. It is a literal Homebrew **keg-relocation placeholder** — meant to be rewritten by Homebrew’s installer when the keg is poured into a Cellar on a target machine. It is *not* a
runtime-resolvable path; it must be rewritten before the binary leaves your build server.
## Scope of the problem inside the bundle
A scan of `NetDrive.app` finds **370 unresolved `@@HOMEBREW_CELLAR@@` references** across **~95 Mach-O files**, including:
- Every Qt framework in `Contents/Frameworks/` (QtCore, QtGui, QtWidgets, QtNetwork, QtSvg, QtScript, QtScriptTools, QtWebSockets, QtQml, QtQuick, QtQmlModels, QtVirtualKeyboard, QtMacExtras, QtPrintSupport, QtDBus) — their own
`LC_ID_DYLIB` and their inter-framework `LC_LOAD_DYLIB` entries
-
Every plugin under `Contents/PlugIns/` (platforms/libqcocoa.dylib, imageformats/*, virtualkeyboard/*, styles, iconengines, printsupport, bearer, platforminputcontexts)
-
The same plugin trees duplicated inside every helper sub-app: `Helpers/ndagent.app`, `Helpers/NetDrive_helper.app`, `Helpers/nd3svc.app`
-
`Frameworks/libgthread-2.0.0.dylib` (also has a `@@HOMEBREW_CELLAR@@/glib/…` reference)
The main `Contents/MacOS/NetDrive` binary is fine — its load commands correctly use `@executable_path/../Frameworks/…`. So the breakage is entirely in the bundled Qt frameworks and plugins, i.e. the artifacts that your build pulled in
from Homebrew’s `qt@5` keg without ever being processed.
## Root cause
Your macOS release pipeline appears to be copying the contents of Homebrew’s `qt@5` Cellar directly into the bundle without running the macOS Qt deployment step. The standard Qt-recommended tool for this is `macdeployqt`:
```
macdeployqt NetDrive.app -verbose=2
```
`macdeployqt` (or an equivalent `install_name_tool`-based step) rewrites every framework’s `LC_ID_DYLIB` and every `LC_LOAD_DYLIB` to use `@rpath/…`, then adds the appropriate `LC_RPATH` (`@executable_path/../Frameworks`) to the
executable. This step is missing from your current pipeline for 3.19.26.
## What works as a customer-side hotfix
For anyone whose 3.19.x is crashing right now, this Bash script restores a launchable bundle by walking every Mach-O inside `/Applications/NetDrive.app`, rewriting `@@HOMEBREW_CELLAR@@///lib/` → `@rpath/`
for both `LC_ID_DYLIB` and `LC_LOAD_DYLIB`, then re-signing the bundle ad-hoc:
```bash
#!/usr/bin/env bash
set -uo pipefail
APP=“/Applications/NetDrive.app”
[[ $EUID -ne 0 ]] && { echo “sudo required”; exit 1; }
while IFS= read -r bin; do
file -b "$bin" 2>/dev/null | grep -q "Mach-O" || continue
chmod u+w "$bin"
id=$(otool -D "$bin" 2>/dev/null | sed -n '2p' | sed -E 's/^\[\[:space:\]\]+//')
if \[\[ "$id" == @@HOMEBREW_CELLAR@@/\* \]\]; then
new_id=$(echo "$id" | sed -E 's|^@@HOMEBREW_CELLAR@@/\[^/\]+/\[^/\]+/lib/|@rpath/|')
install_name_tool -id "$new_id" "$bin"
fi
while IFS= read -r dep; do
\[\[ "$dep" == @@HOMEBREW_CELLAR@@/\* \]\] || continue
new_dep=$(echo "$dep" | sed -E 's|^@@HOMEBREW_CELLAR@@/\[^/\]+/\[^/\]+/lib/|@rpath/|')
install_name_tool -change "$dep" "$new_dep" "$bin"
done < <(otool -L "$bin" 2>/dev/null | awk 'NR>1 {print $1}')
done < <(find “$APP” -type f)
codesign --force --deep --sign - “$APP”
```
Run as `sudo bash fix_netdrive.sh`. Verified working on macOS 12.7.6 / MacBook Pro 11,5 (Intel) against NetDrive 3.19.26. After the patch:
-
`Contents/MacOS/NetDrive` launches and connects to `ndagent`
-
`ndagent`, `nd3svc`, `NetDrive_helper` all launch cleanly
-
Bundle is ad-hoc signed; your codesign identity is replaced (acceptable hotfix, not a long-term answer)
## What we’d like from Bdrive
1. **Add `macdeployqt NetDrive.app` (or an equivalent install-name rewrite step) to your macOS release pipeline** and re-release 3.19.26 with corrected install names.
2. **Audit prior 3.19.x builds** — this almost certainly isn’t unique to .26 and may have been shipping silently for users whose machines happened to have Homebrew Qt installed.
3. **Add a smoke test** to your CI: `otool -L` every Mach-O inside the bundle and fail the build if any output line begins with `@@HOMEBREW_CELLAR@@`. One-liner:
\`\`\`bash
! find NetDrive.app -type f -exec sh -c 'file -b "$1" | grep -q Mach-O && otool -L "$1"' \_ {} \\; 2>/dev/null | grep -q '@@HOMEBREW_CELLAR@@'
\`\`\`
This would have caught the bad build before it shipped.