Class GNotificationCenterDelegate warning message

[xzhang8102]

Environment:
MacOS 26.5.2
Pake-cli version 3.15.3

A warning message shows up after running pake --version:

objc[5740]: Class GNotificationCenterDelegate is implemented in both /Users/user/Library/pnpm/store/v11/links/@img/sharp-libvips-darwin-arm64/1.0.4/9d2feff88774898ea74f4bfdcd28f9540402ea79110712044d82b4b7bc75337c/node_modules/@img/sharp-libvips-darwin-arm64/lib/libvips-cpp.42.dylib (0x138559a28) and /Users/user/Library/pnpm/store/v11/links/@img/sharp-libvips-darwin-arm64/1.2.4/d29911f8b2f719e01296f2c07739516fe217794398cf174a2bc243c1ff4da9f6/node_modules/@img/sharp-libvips-darwin-arm64/lib/libvips-cpp.8.17.3.dylib (0x13b3e1978). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed.

I found that issue #1182 reported the same issue.

Does anyone still run into the same warning message?

[rakeshutekar]

Yes, this still happens, and the good news is it's harmless — it's a warning, not a crash, and it isn't really a Pake bug so much as a transitive-dependency quirk from sharp.

What the message is telling you: two different builds of libvips are loaded into the same process, and both register an Objective-C class named GNotificationCenterDelegate (that class comes from GLib/GIO, which libvips bundles). The dynamic linker warns because two dylibs define the same class, and only one wins.

You can see it in the paths — two different versions of the same package:

@img/sharp-libvips-darwin-arm64/1.0.4/.../libvips-cpp.42.dylib
@img/sharp-libvips-darwin-arm64/1.2.4/.../libvips-cpp.8.17.3.dylib

Pake depends on sharp (^0.34.5) for icon processing, and sharp pulls in @img/sharp-libvips-darwin-arm64 as a platform package. When two sharp versions end up resolvable at once, pnpm links both libvips builds and the CLI process loads both — hence the duplicate-class warning. That's exactly what #1182 diagnosed ("Loads Two Sharp-libvips versions and triggers Objective-C duplicate"), and it's coming from your pnpm store rather than from Pake's own code.

Because only one copy is actually used, the "spurious casting failures and mysterious crashes" the linker threatens don't materialize here — for pake --version (and icon generation in general) it's cosmetic. So if it's just noise you want gone, you have a few options:

1. Collapse to one sharp version. From wherever you installed the CLI:

   pnpm why sharp          # see who's pulling which versions
   pnpm dedupe             # or: pnpm up sharp

   If the two versions come from pake-cli + a globally-linked sharp, deduping usually leaves a single @img/sharp-libvips-darwin-arm64 and the warning disappears.

2. Prune the pnpm store, which is where the two stale builds are lingering:

   pnpm store prune

3. Silence it if you just want a clean console — it doesn't affect the built app, only the CLI run:

   pake --version 2>/dev/null

If you installed pake-cli globally with pnpm and also have sharp elsewhere in the same store, that's the usual way both versions become loadable at once. Which install method did you use (npm i -g vs pnpm add -g vs npx)? That determines which of the above actually clears it, since the duplicate lives in the store feeding your CLI rather than in Pake itself.

[xzhang8102]

Thx for the reply! pnpm dedupe works.