`dlopen` fails

[t-bltg]

I'm wrapping a c++ library and dlopening the resulting shared library fails:

The following patch seems to fix it:

diff --git a/src/CodeTree.cpp b/src/CodeTree.cpp
index e7c2054..15be57d 100644
--- a/src/CodeTree.cpp
+++ b/src/CodeTree.cpp
@@ -804,7 +804,7 @@ std::ostream& CodeTree::generate_jl(std::ostream& o,

   o <<  "\n"
     "using CxxWrap\n"
-    "@wrapmodule(\"" << shared_lib_basename<< "\")\n"
+    "@wrapmodule(joinpath(@__DIR__, \"" << shared_lib_basename<< "\"))\n"
     "\n"
     "function __init__()\n"
     "    @initcxx\n"

Would it be acceptable or should we configure the shared library prefix in the toml configuration file ?

[grasph]

Did you try to include the directory that contains your shared library in your JULIA_LOAD_PATH as done in the different examples (see the setup.sh file) ?

[t-bltg]

Yes, I know about JULIA_LOAD_PATH, the point being wouldn't it be nice to provide a configurable way (via toml file) to avoid using environment variables ?

If the built shared library resides along the generated <module_name>.jl, I'd expect the module to dlopen the shared library automatically without having to populate JULIA_LOAD_PATH (since @__DIR__ expands to the module source files directory) ...

I can propose a PR if we agree that this would be a useful feature.

[t-bltg]

Also, JULIA_LOAD_PATH has no effect on this.

You have to use LD_LIBRARY_PATH=$(pwd) instead, and anyone knows that this shouldn't be recommended.

I really think there should be a configurable option that uses @__DIR__ by default (creating an absolute path), but can be set to a relative path as before for retro-compatibility.

[grasph]

Hello @t-bltg ,

The default you are proposing is assuming the shared library to be in the same directory as the julia module source. Although it is the case for the examples of the package, it is an unusual choice. Current default, which might not be ideal, is better as it relies on Julia and OS defaults.

Note that the recommended way to ship the library is as an artifact, possible using _jll (in which case the library will be in its own package).

I plan to modify the way the julia module code is produced. The master module file should be view as an example. The user will typically write his own file to include his customization. I will then see if I add a parameter to specify the library file name path. I would like to keep the configuration at minimal: automatic code generation makes sense only if the configuration is simpler that the code to generate, while here it is the matter of only simple lines of simple code.

Philippe.