Where to put dylibs when packaging?

[deshan]

• Version: 22.8.0

• Electron Version:9.0.5
• Electron Type (current, beta, nightly):current

• Target: MacOS

I am packing an electron app with React, few dylibs, and a native node module.

My packaging structure is

Content
----Frameworks
---------coreAPI_addon.node
----Info.plist
----MacOS
---------DesktopApp
---------libCoreAPI.dylib
----PkgInfo
----Resources

Please note: coreAPI_addon.node module is in Frameworks directory and libCoreAPI.dylib is in MacOS directory

I can run the application only in the command prompt. If I double click open the DesktopApp.app I am getting

Uncaught Error: Cannot open ./coreAPI_addon.node: Error: dlopen(./coreAPI_addon.node, 1): Library not loaded: libCoreAPI.dylib

When running from command prompt I changed the directory to 'MacOS'. Then it works.

cd ./dist/mac/DesktopApp.app/Contents/MacOS/
./DesktopApp

Could you please tell me where to put dylibs when packaging?

package.json

...
"build": {
    "asar" : true,
    "files": [
      "./dist/webpack/**/*",
      "./electron.js"
    ],
    {
        "from": ".",
        "to": "MacOS",
        "filter": ["*.dylib"]
      },
      {
        "from": "build/Release",
        "to": "Frameworks",
        "filter": ["*.node"]
      }
    ]
  },

[deshan]

Am I doing wrong here? the dylibs supposed to put in Frameworks directory? or in Resources?

libCoreAPI.dylib is an dependency of native module coreAPI_addon.node.
coreAPI_addon.node is in the Framework directory and it loads successfully. But complains libCoreAPI.dylib not loaded when I double click run the app which created by electron-build.

Uncaught Error: Cannot open ./coreAPI_addon.node: Error: dlopen(./coreAPI_addon.node, 1): Library not loaded: libCoreAPI.dylib
Referenced from: desktop_app/dist/mac/DesktopApp.app/Contents/Frameworks/coreAPI_addon.node
Reason: image not found
at Object. (main.js:1)
at Object. (main.js:1)
at t (main.js:1)
at Module. (main.js:38)
at t (main.js:1)
at main.js:1
at main.js:1

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[deshan]

it was a dylib internal path issue, changed rpath using install_name_tool
if someone needs
install_name_tool -change ${depfileName} @rpath/${depfileName} ${corefile}

[dceddia]

I ran into a similar problem, and it was also related to rpath. Running otool -L on the node addon shed some light on the paths it was expecting:

otool -L bindings.darwin-arm64.node
bindings.darwin-arm64.node:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1853.0.0)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	@rpath/libavcodec.framework/libavcodec (compatibility version 59.0.0, current version 59.15.102)
	@rpath/libavformat.framework/libavformat (compatibility version 59.0.0, current version 59.10.100)
	@rpath/libavutil.framework/libavutil (compatibility version 57.0.0, current version 57.13.100)
	@rpath/libswresample.framework/libswresample (compatibility version 4.0.0, current version 4.0.100)
	@rpath/libswscale.framework/libswscale (compatibility version 6.0.0, current version 6.1.102)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

The ones with @rpath are expected to be relative to the app binary (Electron.app/Contents/MacOS/Electron). I found this post on how dynamic library loading works to be super helpful.

I fixed this by copying the libraries into the Frameworks folder (Electron.app/Contents/Frameworks) but it would also probably work to modify those paths with install_name_tool and put the libraries somewhere else in the .app.