Lua's ffi.load("library") results in a cannot open shared object file: No such file or directory error.
As a temporary solution I can provide the absolute or relative path to the library.
Eg. ffi.load("./liblibrary.so").
I've read that LUA_PATH and LUA_CPATH need to be set.
Eg:
export LUA_PATH="$PWD/src/?.lua"
export LUA_CPATH="$PWD/lib/?.so"
Setting LUA_PATH enables me to "require" lua files from other directories, but LUA_CPATH doesn't seem to help with loading shared objects.
ffi.load uses the normal dlopen mechanism of your operating system.
On Linux, this means that you need to add your libraries path to the LD_LIBRARY_PATH variable.
Once LD_LIBRARY_PATH is set, Lua is able to find the library.
I found this answer helped me debug my situation by printing any matching libraries on LD_LIBRARY_PATH.
Relevant FFI documentation
Related
First Method (export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH):
Based on this method, I can compile h5_crtdat.f90 through "gfortran h5_crtdat.f90 -fintrinsic-modules-path /usr/local/include -lhdf5_fortran" successfully. And I can run it as well.
Second Method (-Wl,-rpath):
Based on this method, I can compile h5_crtdat.f90 through "gfortran h5_crtdat.f90 -fintrinsic-modules-path /usr/local/include -lhdf5_fortran -Wl,-rpath,/usr/local/lib" successfully. However, after type in "./a.out" I got the following error
"./a.out: error while loading shared libraries: libhdf5.so.200: cannot open shared object file: No such file or directory".
Questions:
I have searched the google that these two methods can produce the same effect when linking shared library in gfortran compiler. Thus, I do not know why I will get the errors when the second method is used.
These two serve a different purpose.
LD_LIBRARY_PATH says where to search for shared libraries when executing some executable that has already been compiled and linked. It is possible, but not guaranteed, that some linker will alsonconsider this path for the actual linking, but there are other variables, like LIBRARY_PATH for that.
-Wl,-rpath says where to link shared libraries when building the executable. It has no effect when running the executable.
You must set LD_LIBRARY_PATH or some equivalent when running the executable so that the necessary libraries for the run can be located.
When writing luarocks install gumbo
In the location/directory of my luarocks file in cmd, I am getting the following error
Warning: Could not find Lua 5.3 in PATH.
Modules may not install with the correct configurations. You may want to specify the path prefix to your build of Lua 5.3 using --lua-dir
Installing https://luarocks.org/gumbo-0.5-1.src.rock
Error: Failed finding Lua library. You may need to configure LUA_LIBDIR.
I've added lua53.exe to the same directory, and added the file both to my user variables and system variables in control panel.
Not sure if worth mentioning, but when running lua53.exe and trying to use luarocks install gumbo from there,
the lua53 cmd-like window responds with stdin:1: syntax error near 'install'
I was hoping to do some web scraping with lua, and later on building a World of Warcraft addon that utilizes gumbo to show certain helpful information within the WoW client, but I can't seem to even get the most basic stuff to work...
Setting up LuaRocks on Windows is annoying and I'm not familiar with it myself. If you added both the LuaRocks and Lua 5.3 Windows binaries (Executables and Includes) to your Path system variable:
luarocks path prints the commands for setting up the LUA_PATH and LUA_CPATH system variables.
The config.lua file tells you what your variables.LUA_LIBDIR value is. You can check it with luarocks config. For me that file would be in:
C:/Users/Ketho/AppData/Roaming/luarocks/config-5.3.lua
otherwise you can create an empty file there and put in this line to point it to wherever your Lua folder is:
variables.LUA_LIBDIR = "C:/lua-5.3.5_Win32_bin"
variables.LUA_INCDIR = "C:/lua-5.3.5_Win32_bin/include"
As for using gumbo to show information within WoW, the addon environment is sandboxed. Unless you meant you just want to get the data to hardcode into your addon.
(Background: In a docker container on a NVidia Jetson TX2 board I have decompressed NVidia's Linux For Tegra tarball which contains lots of drivers and shared object files, some of which provide GStreamer element factories which produce elements that I use in my GStreamer pipeline. I am trying to run the pipeline in the docker container.)
However, there is an element in my GStreamer pipeline (on this Tegra board), called 'omxh264enc', which I haven't been able to create.
I've put the corresponding 'libnvomx.so' in my drivers folder which is in the exported paths GST_PLUGIN_PATH and the LD_LIBRARY_PATH.
ldd -r does not show any missing libraries for libnvomx.so
HOWEVER when I try and run the pipeline, output includes
WARN omx gstomx.c:2826:plugin_init: Failed to load configuration file: Valid key file could not be found in search dirs (searched in: /root/.config:/etc/xdg as per GST_OMX_CONFIG_DIR environment variable, the xdg user config directory (or XDG_CONFIG_HOME) and the system config directory (or XDG_CONFIG_DIRS)
INFO omx gstomx.c:2831:plugin_init: Using default configuration
ERROR omx gstomx.c:2894:plugin_init: Core '/usr/lib/aarch64-linux-gnu/tegra/libnvomx.so' does not exist for element 'omxh264enc'
WARN GST_PLUGIN_LOADING gstplugin.c:526:gst_plugin_register_func: plugin "/gst_1.8.3/libs/gstreamer-1.0/libnvomx.so" failed to initialise
and when I use GST_DEBUG=3 gst-inspect-1.0 libnvomx.so, libnvomx.so is blacklisted.
Plugin Details:
Name libnvomx.so
Description Plugin for blacklisted file
Filename /gst_1.8.3/libs/gstreamer-1.0/libnvomx.so
Version 0.0.0
License BLACKLIST
Source module BLACKLIST
Binary package BLACKLIST
Origin URL BLACKLIST
I have copied libnvomx.so into /usr/lib/aarch64-linux-gnu/tegra but this did not make a difference (probably because libnvomx is blacklisted).
I don't know where to find the gstomx.conf file, where maybe I can change the path /usr/lib/aarch64-linux-gnu/tegra/libnvomx.so to my designated drivers folder (/gst_1.8.3/libs/gstreamer-1.0/). I have used 'find' on /etc and some other folders but didn't find it (I didn't actually find a .config folder on the system).
(There are also other plugins with missing symbols, nvidia_drv.so with undefined symbol TimerSet and libglx.so with undefined symbol serverClient. I would like to find out what is suppose to provide these symbols? But these are not (direct) dependencies of libnvomx.so)
So how can I initialise / unblacklist libnvomx.so so I can use 'omxh264enc'? Do I need to find / make a gstomx configuration file or can I make it work with the default configuration? I read somewhere there may be a solution using a 'symlink' but at the moment I'm not familiar with what these are or how these work.
Let me know if you need more info, thanks.
I am following the tutorial : http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html
when I reach the part where I am supposed to set the library path :
Unix or Linux:
LD_LIBRARY_PATH=`pwd`
export LD_LIBRARY_PATH
Windows NT/2000/95:
set PATH=%path%;
Neither of these work in cygwin. I keep getting an error when trying to run my program.
Cygwin doesn't use LD_LIBRARY_PATH, it looks for shared libraries in PATH, so try:
export PATH=`pwd`:$PATH
That will add the current directory to the front of the PATH.
Is that
LD_LIBRARY_PATH=$(pwd)
and you just messed up the html, or are you really running:
LD_LIBRARY_PATH=pwd
If the latter, try adding the $() to get the current working directory into the path. Also, you can
echo $LD_LIBRARY_PATH
to ensure it contains what you want. You might consider doing
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(pwd)
to avoid discarding previous contents of the path.
I'm using cmake and make to compile a project using an external library (speex).
This library is found by the find_library command in my CMakeLists.txt.
The only problem is: the default include path of cmake does not include /usr/local/include/, that is the location of speex's headers.
I do not want to add /usr/local/include/ to the search path in the CMakeLists.txt because it would (I suppose) generate an error on windows where such path doesn't exist.
Moreover, that would be a dirty trick, I'm not quite fond of this solution.
Do you know a solution to this problem which would be portable and clean ?
Thank you for your time.
Try using a full-blown speex find module, either created from scratch, or based on something found with http://www.google.com/search?q=findspeex.cmake
Punt the configuration to the user via the command line, e.g.
cmake -DSPEEX_PATH=/usr/local/include
Use the PATH argument of find_library to specify other places to search. If the path doesn't exist it shouldn't produce an error.