search

JohnAustinDev / xulsword

Automatically exported from code.google.com/p/xulsword
17 stars 5 forks source link

LD_LIBRARY_PATH #265

Closed JohnAustinDev closed 2 years ago

JohnAustinDev commented 2 years ago

The LD_LIBRARY_PATH environment variable must currently be set, even in the production build, or the program fails to start. Also, the libxulsword.so library is not being packaged by Electron. Maybe what would be best:

tomr2k commented 2 years ago

The LD_LIBRARY_PATH environment variable can be easily eliminated once we know where the libxulsword.so.* shared object will reside in the product hierarchy. Is the src/main/modules directory packaged with the product or is there a better/different location?

JohnAustinDev commented 2 years ago

It should probably be in the same directory as libxulsword.node, which in production is located at: /resources/app/node_modules/libxulsword/bin/linux-x64-89/libxulsword.node.

JohnAustinDev commented 2 years ago

Another idea which would be easier and less fuss going forward, is to static link a libxulsword-static.a to libxulsword.node. Then there would be only libxulsword.node and no other libraries to keep track of. It seems you just need to link to the .a file instead of the .so? This would also simplify packaging for the other operating systems as well, since they might need different path finagling.

tomr2k commented 2 years ago

I think my earlier concern is moot since it looks like the node api build process produces its own executable located under the main node_modules directory.  The link to the libxulsword.so library (either through LD_LIBRARY_PATH, relative or absolute) is only required during the node module build process and the original library is not required at runtime.  I could be wrong but will verify this shortly.  ;-)

On Wednesday, January 19, 2022, 03:20:54 PM PST, JohnAustinDev ***@***.***> wrote:

Another idea which would be easier and less fuss going forward, is to static link a libxulsword-static.a to libxulsword.node. Then there would be only libxulsword.node and no other libraries to keep track of. It seems you just need to link to the .a file instead of the .so? This would also simplify packaging for the other operating systems as well, since they might need different path finagling.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: @.***>

JohnAustinDev commented 2 years ago

A solution has been committed which uses LD_LIBRARY_PATH at runtime, but not at build time. This is a good solution for Linux and works in both development and production now. Other methods may still be needed for Windows and MAC builds.