You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The general problem with the rpath there is that $SRCDIR is an absolute path and ends up in the final binary (executable or shared lib depending the Go build target) for linux/macOS/Android. When executing the binary, it will work on the developer's machine but fail to find the shared lib if deployed anywhere else.
The -rpath flag on Windows does nothing I think - runpaths are a Unix concept and don't exist on Windows. I am a bit surprised it does not throw a linker error on Windows, but maybe it just ignores it. It is probably best to delete for Windows for clarity.
On linux/macOS the rpath flag is basically making go run (or executing the binary after go build) work, so that the binary knows where to find the shared lib at runtime. That is practical for the developer but also not ideal, as it puts an absolute path pointing to the development folder into the resulting binary, which will fail when the binary is deployed elsewhere. See the commit msg here for all the details: BitBoxSwiss/bitbox-wallet-app#2373.
This should be documented and the user should know how to get rid of the bad rpath/runpath in production binaries (install_name_tool ... on macOS and chrpath ... on linux)
Maybe a build tag could be introduced and documented that should be enabled for production builds, to not include the rpath there. The user can add custom rpaths (like -rpath=$ORIGIN or something relative to that) using CGO_LDFLAGS or after the build has finished using the above mentioned tools.
The rpath part can likely be dropped for Android as well - devs will not run go run there, and having a absolute path in the Android libs to the development folder can only hurt not help for the same reason as above.
The text was updated successfully, but these errors were encountered:
https://github.com/breez/breez-sdk-go/blob/main/breez_sdk/cgo.go#L13C1-L13C97
The general problem with the rpath there is that $SRCDIR is an absolute path and ends up in the final binary (executable or shared lib depending the Go build target) for linux/macOS/Android. When executing the binary, it will work on the developer's machine but fail to find the shared lib if deployed anywhere else.
The -rpath flag on Windows does nothing I think - runpaths are a Unix concept and don't exist on Windows. I am a bit surprised it does not throw a linker error on Windows, but maybe it just ignores it. It is probably best to delete for Windows for clarity.
On linux/macOS the rpath flag is basically making
go run
(or executing the binary aftergo build
) work, so that the binary knows where to find the shared lib at runtime. That is practical for the developer but also not ideal, as it puts an absolute path pointing to the development folder into the resulting binary, which will fail when the binary is deployed elsewhere. See the commit msg here for all the details: BitBoxSwiss/bitbox-wallet-app#2373.install_name_tool ...
on macOS andchrpath ...
on linux)-rpath=$ORIGIN
or something relative to that) usingCGO_LDFLAGS
or after the build has finished using the above mentioned tools.The rpath part can likely be dropped for Android as well - devs will not run
go run
there, and having a absolute path in the Android libs to the development folder can only hurt not help for the same reason as above.The text was updated successfully, but these errors were encountered: