Morning,
I would like to import my own library to Veins (v4.4) project.
I followed this tutorial to compile a shared library.
I've also stripped the shared library with this command:
strip --strip-unneeded libfoo.so
since I've noticed that system libraries such as sqlite3 are compiled in stripped mode.
Then I imported the library from
1.Project->Properties->Paths and Symbols :
1.1 includes
1.2 Libraries
1.3 Library Paths
2.Makemake-> Src->Options->Link-> Additional Libraries
However, the problem is that when I use the imported library I still get an error of "undefined symbol "; so I suppose the library is not correctly imported or read by the simulator.
Any suggestion?
Thanks for helping
How to load additional libraries in your simulation is documented in the user manual's chapter on running simulations.
In brief, you will need to add -l foo to the command line parameters to make the simulation load libfoo.so when it starts.
If you use the IDE to start the simulation, you can edit your simulation's run configuration: Choose menu item Run > Run Configurations..., then on the Main tab click on More >>, append the name of your library (e.g. foo if your library is called libfoo.so, or foo bar if you want your simulation to load libfoo.so and libbar.so on startup) to the Dynamic libraries text field. After launching, you will see the aforementioned command line parameter -l foo being used by the IDE to run the simulation.
If you are unsure about where to put your library, a related question has a discussion on this: <!> Error during startup: Cannot load library in OMNET++ project while using sqlite3
Related
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
I cannot load a lua module, which is a 32bit c++ dll.
The lua module and the lua code is in the same folder.
in c++ code:
extern "C" __declspec(dllexport) int luaopen_luartmidi(lua_State *L) {
...
}
lua first line:
local luartmidi = require 'luartmidi'
When i run the lua code with vs code lua 32bit debugger i get
error message:
Exception has occurred: [C]:-1: error loading module ... from file ...
The specified function could not be found
Dependency Walker says LUA.DLL is missing. When i copy lua.dll in the same folder i get error
c:Users/xyz/.vscode/extensions/actboy168.lua-debug-1.23.1/runtime/win32/lua53/lua.exe: multiple Lua VMs detected
This happens when you link with a lua interpreter statically and then try to load an external module that links against a Lua DLL (and expects a lua.dll or similarly named library to be present). You can't both have a statically compiled interpreter and one loaded from a DLL to be present in the same process (the "multiple Lua VMs detected" message is triggered by a check against this condition).
You have three options:
Compile everything statically (don't load any external modules)
Compile everything dynamically (don't link the Lua interpreter statically)
Use a proxy library that will forward API calls from external libraries to statically linked Lua interpreter (will require exporting Lua symbols and writing a proxy library). See http://lua-users.org/wiki/LuaProxyDllFour links for the code and details (it's for Lua 5.1, but you can tweak the script for Lua 5.3).
There is a laptop on which I have no root privilege.
onto the machine I have a library installed using configure --prefix=$HOME/.usr .
after that, I got these files in ~/.usr/lib :
libXX.so.16.0.0
libXX.so.16
libXX.so
libXX.la
libXX.a
when I compile a program that invokes one of function provided by the library with this command :
gcc XXX.c -o xxx.out -L$HOME/.usr/lib -lXX
xxx.out was generated without warning, but when I run it error like this was thrown:
./xxx.out: error while loading shared libraries: libXX.so.16: cannot open shared object file: No such file or directory , though libXX.so.16 resides there.
my clue-less assumption is that ~/.usr/lib wasn't searched when xxx.out is invoked.
but what can I do to specify path of .so , in order that xxx.out can look there for .so file?
An addition is when I feed -static to gcc, another error happens like this:
undefined reference to `function_proviced_by_the_very_librar'
It seems .so does not matter even though -L and -l are given to gcc.
what should I do to build a usable exe with that library?
For other people who has the same question as I did
I found a useful article at tldp about this.
It introduces static/shared/dynamic loaded library, as well as some example code to use them.
There are two ways to achieve that:
Use -rpath linker option:
gcc XXX.c -o xxx.out -L$HOME/.usr/lib -lXX -Wl,-rpath=/home/user/.usr/lib
Use LD_LIBRARY_PATH environment variable - put this line in your ~/.bashrc file:
export LD_LIBRARY_PATH=/home/user/.usr/lib
This will work even for a pre-generated binaries, so you can for example download some packages from the debian.org, unpack the binaries and shared libraries into your home directory, and launch them without recompiling.
For a quick test, you can also do (in bash at least):
LD_LIBRARY_PATH=/home/user/.usr/lib ./xxx.out
which has the advantage of not changing your library path for everything else.
Should it be LIBRARY_PATH instead of LD_LIBRARY_PATH.
gcc checks for LIBRARY_PATH which can be seen with -v option
i'm tryin to debug (actually i just want to understand the program on assembly level) a program. Usin gdb is ok but in tui mode it would be just great, unfortunately i get an error when i'm debuggin in tui while displaying the assembly and source code (-g option in gcc) mode sayin: error while reading shared library symbols
I can run the program if i do not show the assembly code but that is not what i want, i really want to step through every assembly line to fully understand the program. Also, when i try this with si sometimes i get an error for example in printf but that's another story
so any tips? Note:this is not a bug of my program, i tried this with other programs
Your shared libraries were not compiled with symbols enabled. You need to look for, usually, "debug" versions of gcc libraries (or your other libraries that you are linking against). If you have custom libraries that you are building, add the -g option to the gcc commands that are being run to compile them.
I have a following setup. Although my working setup deals with ARM compiler Real View Developer Suite (RVDS) 3.2 on a Windows host, the situation could be generic for any other C compiler on any host.
I build a ARM library (static library - .a file) of C code using RVDS 3.2 compiler toolchain on Windows host. Then I link this library with an application using an ARM-Linux compiler toolchain on a Linux host, to get a ARM executable. Now when I try to debug this generated ARM executable on Linux using gdb, by trying to put a breakpoint in some function which is present in the library that is linked, gdb is not able to put breakpoint there citing source not found. So I manually copied all the source files(*.c) used to create the library in the Linux folder where the executable file is present. Still gdb fails to put a breakpoint.
So now I started thinking:
How can I do source level debugging of this library which I create on Windows using a different compiler chain by launching the executable which is generated by linking this library to an application, in gdb. Is it possible? How can I do it? Is there any compiler option in RVDS compiler toolchain to enable this library source level debug?
Do I need to copy the source files to linux in exactly same folder structure as that is present in windows for those source files?
You could try to see if mimicking the exact same directory structure works. If you're not sure what directory structure the compiler annotated in the debug info in the executable, you can always look at it with dwarfdump (on linux).
First, GDB does not need any source to put breakpoints on functions; so your description of what is actually happening is probably inaccurate. I would start by verifying that the function you want to break on is actually there in the binary:
nm /path/to/app | grep function_desired
Second, to do source level debugging, GDB needs debug info in a format GDB understands. On Linux this generally means DWARF or STABS. It is quite possible that your RVDS compiler does not emit such debug info; if so, source level debugging will not be possible.
Did you build the library with debugging enabled (-g option)? Without that, there would be difficulties identifying lines etc.
I've found that -fPIC will cause this sort of issue, but the only work around I've found is to not use -fPIC when I want to debug.