Linux x64 build failing #18
Comments
|
From my latest tests:
|
|
Another update: running |
|
When testing the sample application from the command line, a simple
Running Therefore trying However this does not get rid of the previous error. |
|
This is the strangest thing, not even this gets rid of the previous error: settings.resources_dir_path = Paths.get("/home/johnrdorazio/.BibleGetPluginOpenOffice/JCEF/").toAbsolutePath().normalize().toString();
settings.locales_dir_path = Paths.get("/home/johnrdorazio/.BibleGetPluginOpenOffice/JCEF/locales/").toAbsolutePath().normalize().toString();I can avoid the settings.pack_loading_disabled = true;However it still complains about not finding the locale pak files. |
|
Interesting, setting |
|
ooookkkk I fixed the error for the pak files not loading, it was due to the |
|
to fix the message from above
and that error message is gone. However it seeems that the --disable-gpu switch is not working, still getting the libGL errors... But this could very well just be the WSL2 Ubuntu instance which isn't exactly meant for the GPU stuff, perhaps in a regular Ubuntu instance we won't have these errors. Needs testing |
|
just a note to self, this seems to fix the graphics error on WSL2: export LIBGL_ALWAYS_INDIRECT=1Add this to bash profile (before The error was: libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrastTest by running: glxinfo | grep OpenGL(The package mesa-utils must be installed already: Solution was here: https://askubuntu.com/a/1285593/433276 |
|
build is now fixed with the new Installer process. Last commit to fix this process is 0657f21 . |
so here's what we've got so far for a Linux build:
the JCEF linux x64 build was built with JDK 11, so trying to use JDK 8 (1.8) will not work, the build will not succeed. Using JDK 11 works but introduces new problems: in order to dynamically load the JCEF native libraries at runtime we can use a reflection hack to reset the System user path and make sure that the path to the JCEF native libraries are in the user path and reset the
java.library.pathwith this new path. However this hack only works with JDK 8, not with JDK 11. For JDK >= 9 there is however another approach using Lookup and MethodHandles (see https://stackoverflow.com/questions/15409223/adding-new-paths-for-native-libraries-at-runtime-in-java). This seems to be working, however the JCEF component is not being initialized...studying the sample application provided by the JCEF build for Linux x64 I can see that the
LD_LIBRARY_PATHenvironment variable also needs to be set with the path to the JCEF native libraries. The plugin code is dynamically downloading the JCEF build from a github release and saving it to this folder: System user path + '/.BibleGetPluginOpenOffice/JCEF' . So this path is needed in theLD_LIBRARY_PATHenvironment variable. Perhaps this is all that is needed to get the JCEF component to work? So how do we set this environment variable? Can we reset it at runtime?For testing purposes I tried exporting the
LD_LIBRARY_PATHvariable in my Ubuntu 20.04 instance (I'm using WSL2 on Windows 10, and using X11 forwarding in order to be able to launch graphical interfaces = Netbeans, Apache OpenOffice...), and I added aSystem.out.println()in the code to see the value of theLD_LIBRARY_PATHvariable. This shows me that the variable now contains paths that weren't in the variable before on the terminal, but it does not contain the path to the JCEF native libraries. So I'm guessing the Ant script in Netbeans is maybe overwriting this variable during the build? So next step to test a solution is perhaps to figure out how to set this variable in the Ant script? Or find a way to overwrite it again at runtime? I tried using the same method used to reset thejava.library.path, to try and reset theLD_LIBRARY_PATHvariable, but didn't succeed, it seems to generate an exception. And I don't believe it's a recommended approach, environment variables really should be set in the environment before launching a Java runtime and the JDK releases after JDK 8 have been discouraging overwriting these variables at runtime, they started showing warnings to discourage people from using this approach...The text was updated successfully, but these errors were encountered: