DllNotFoundException libpjsipDll Mono - dll

I've a problem to execute a program with Mono in the terminal, (mono program.exe). An error appears : "System.DllNotFoundException : libpjsipDll.so "
however my library exists and I've setted my 2 environment variables : LD_LIBRARY_PATH and MONO_PATH in the directory where the file is.
I don't understand why this error occured ?
Anyone has an idea ?
I've :
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped (CPU architecture)
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),dynamically linked, not stripped (third-party lib)
I try MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll".
and I obtain an : undefined symbol : Pa_GetErrorText
I try to install PortAudio but I doesn't work always :-(
Thanks in advance.
Narglix

First of all, make sure that the letter casing is correct in that the library you are calling and the assembly on disk have the same case. Linux is picky about it.
I assume that you are using P/Invoke DLLImport? What is the actual code you are using here? You library (libpjsipDll.so) is not managed code of course.

Is not a problem about loading, is a problem about another dependency dll, just run this code and make sure the libpjsipDll.so is where the callingApp.exe is executing.
//I tried this in ubuntu $ sudo apt-get install libssl0.9.8:i386
I discovered that running my App like this:
$ MONO_LOG_LEVEL=debug mono MyApp.exe
Here is my question, where you can find adittional info:
MonoDevelop and libpjsipDll.so library on Ubuntu. System.DllNotFoundException

Related

Cannot compile PDDL 2.1 Temporal Planner POPF on Ubuntu 20.04.1 LTS

I need a temporal planner that supports durative-actions in PDDL, I was following this youtube guide, but I can't make the popf planner work.
I'm getting this error when making popf:
/home/virginia/Scaricati/popf/src/VALfiles/TimSupport.cpp:1392:36: required from here
/usr/include/c++/9/bits/stl_tree.h:1117:16: error: no type named ‘value_type’ in ‘struct std::iterator_traits<TIM::getConditionally<std::_Rb_tree_const_iterator<TIM::Property*> > >’
1117 | __enable_if_t<!__same_value_type<_InputIterator>::value>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [src/VALfiles/CMakeFiles/Inst.dir/build.make:154: src/VALfiles/CMakeFiles/Inst.dir/TimSupport.o] Errore 1
make[1]: *** [CMakeFiles/Makefile2:213: src/VALfiles/CMakeFiles/Inst.dir/all] Errore 2
I used these commands:
mkdir build
cd build
cmake path_to_src_folder
make
After the installation process I expected to have the file 'build/popf/popf-clp' as a binary of popf.
Obviously, since I have an error, I don't have it.
I am using Ubuntu 20.04.1 LTS.
I think this is related to the fact that the VAL code is quite old and incompatible with the newer C++ libraries. Try putting it inside a Singularity file (very similar to Docker, but for some performance reasons AI Planning community prefers Singularity) which uses Ubuntu 16.04 as its base image. Then change your planner invocation scripts to run the singularity image instead (which you could then set in VSCode).
Refer to this very similar issue (SMTPlan and POPF use the same VAL code which is giving you problems):
https://github.com/KCL-Planning/SMTPlan/issues/10#issuecomment-660515454
Further down there is a reference to the Singularity file I had used, but you would need to change it to include your POPF compilation steps instead of SMTPlan.
I think I had the exact same error. And finally, I tried this fork version that compiled on "first try" on my Ubuntu 22.04 (after apt installed dependancies)
https://github.com/DaniGarciaLopez/popf

jpype.getDefaultJVMPath() fails when I try accessing JVM from python3

I am currently using Python3, java8, jpype 0.6.3 version on windows10.
jpype.getDefaultJVMPath() fails with an error :
raise JVMNotFoundException("No JVM shared library file ({0}) "
jpype._jvmfinder.JVMNotFoundException: No JVM shared library file (jvm.dll) found. Try setting up the JAVA_HOME environment variable properly.
My JAVA_HOME points to C:\Program Files (x86)\Java\jdk1.8.0_241
If I try starting JVM directly by passing the jvm.dll path("C:\Program Files (x86)\Java\jdk1.8.0_241\jre\bin\client\jvm.dll) python program crashes.
I have already given executable permission to .dll file
Could anyone please help me fix this issue for the above system specifications
It is possible that your JVM architecture (32 bit) does not match your Python (64 bit). This would cause the symptoms you are describing.
It turns out that the shared code I was using required a specific version of one of the drivers. I still don't understand it all enough to explain why that was but with the older driver version (from a colleague) everything works!
from jpype import *
startJVM("/home/user_name/Downloads/ideaIC-2022.2.3/idea-IC- 222.4345.14/jbr/lib/server/libjvm.so", "-ea")
java.lang.System.out.println("hello world")
shutdownJVM()
This works for me
set the path manually
startJVM("/home/user_name/Downloads/ideaIC-2022.2.3/idea-IC- 222.4345.14/jbr/lib/server/libjvm.so", "-ea")
If this path is not correct for you
Search for this file libjvm.so inside partition computer on linux
Then copy the file path

Systemtap libdwfl error on Linux

I am tying to work/setup the Systemtap tool for profiling OS procesess, on a Virtual Linux. I am using VirtualBox to run the image. Via
rpm -q kernel
and
cat /proc/version
The version obtained is:
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze4)
I have correctly downloaded and installed the tool and wrote a simple program (.stp). However I keep getting the same error, which I have searched information in many places without success:
After executing:
sudo stap my_profiler.stp
I get:
semantic error: libdwfl failure (all kernel modules found): no error
Pass 3: translation failed. Try again with another '--vp 001' option.
According to https://sourceware.org/systemtap/SystemTap_Beginners_Guide/errors.html
⁠semantic error: libdwfl failure
There was a problem processing the debugging information. In most cases, this error results from the installation of a kernel-debuginfo package whose version does not match the probed kernel exactly. The installed kernel-debuginfo package itself may have some consistency or correctness problems.
I have found no relevant information on the "kernel-debuginfo" package. I have also tried the verbose option without benefit. I even tried with an old Snapshot of the VM. Any ideas?
The code of the .stp program I ran:
probe timer.profile{
printf("Process: %s\n", execname())
printf("Process ID: %d\n", pid())
}
Found the problem!!!! It seemed that I was using the wrong version of the Linux Kernel. I was using the default kernel supplied by the version I wrote in the question. It seems that that version (the 2.6.32-5-686 one) has problems with the debug-info so all I did was try the same with another version (the Linux version 3.9.6 with gcc version 4.7.2 Debian 4.7.2-5) and it worked without trouble :)

JNI - compile dll as 64 bit

I compile my .dll with the following command: gcc -mno-cygwin -I"/cygdrive/c/Program Files/Java/jdk1.7.0_04/include" -I"/cygdrive/c/Program Files/Java/jdk1.7.0_04/include/win32" -Wl,--add-stdcall-alias -shared -o CalculatorFunctions.dll CalcFunc.c
I use GlassFish for Eclipse. The whole system is a CORBA client-server. When I start the server from Eclipse - it's fine. But when I try to run the server from the CMD (because I want to set a port and host address for the server) it gives me: Exception: ... .dll: Can't load AI 32-bit .dll on a AMD 64-bit platform
I searched through other topics and saw that I should try with changing my JDK to 32 bit - didn't work again.
So the other solution I read about is to compile the .DLL as 64 bit. What command I need to use or how I do that at all ?
Thanks in advance! :)
You need not only a command but whole 64-bit MinGW toolchain - a 64bit compiler in the first place. Then the parameters to your gcc invocation should work the same.
Beware that 64bit is not just a matter of compilability. Primitive data types have different sizes, so any code making assumptions without sizeof checking is a potential issue. Most prominently, pointer arithmetic.

RockMongo, "Unable to load dynamic library '/.../mongo.so' - wrong ELF class: ELFCLASS64 in Unknown"

I just installed RockMongo by extracting all the files to a lampp web folder /opt/lampp/htdocs/rockMongo/. Visiting index.php shows
To make things right, you must install php_mongo module. Here for
installation documents on PHP.net.
I followed the instructions there (I had to install php-pear):
sudo pecl install mongo
Add the following line to php.ini: extension=mongo.so
Now, when I start the web server (apache), I get the following warning, repeated hundreds of times:
Warning: PHP Startup: It is not safe to rely on the system's timezone
settings. You are required to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'America/New_York' for
'EDT/-4.0/DST' instead in Unknown on line 0
and also this warning a single time:
Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php5/20090626/mongo.so' - /usr/lib/php5/20090626/mongo.so:
wrong ELF class: ELFCLASS64 in Unknown on line 0
The index page stills shows the same message (which means that class_exists("Mongo") returns false)
I tried putting in the absolute path to mongo.so, but that didn't do anything. What's going on?
edit: I used
$ file /usr/bin/php5
/usr/bin/php5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
which seems to suggest my php installation is 64 bits, yet when I print out PHP_INT_MAX I get 2147483647 which seems to indicate my installation is 32 bits. How can I know the "bitness" of my php installation?
From the second PHP warning, it looks like you've mixed 32bit code and a 64bit library.
Make sure all the stuff you've downloaded is of the same "bitness" as your PHP installation.