I have a wireshark plugin code which compiles and generates .so files perfectly under Ubuntu 16. This dissector was written for wireshark 1.6 and the plugin runs perfectly under wireshark 1.6.
However when I try to use this plugin for wireshark 2(or any wireshark version higher than 1.6) following errors show -
Couldn't load module
/home/th89ct/.config/wireshark/plugins/plugin-1_0_0.so:
/home/th89ct/.config/wireshark/plugins/plugin-1_0_0.so: undefined
symbol: tvb_length
Couldn't load module
/home/th89ct/.config/wireshark/plugins/plugin--1_0_0.so:
/home/th89ct/.config/wireshark/plugins/plugin--1_0_0.so: undefined
symbol: check_col
so I wanted to edit the code by replacing the methods - as after googling I've found that these methods do not belong to the new wireshark API.
but the problem is every time I edit the code - even by only putting a space in a blank space - following error appears -
*gcc -c -DHAVE_CONFIG_H -I/usr/include/wireshark -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -DINET6 -D_U_=attribute((unused)) -Wall -Wpointer-arith -g -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -fPIC -DPIC packet-ife.c -o packet-ife.o packet-ife.c:105:23: fatal error: epan/emem.h: No such
file or directory #include
^ compilation terminated. Makefile.linux:28: recipe for target 'packet-ife.o' failed make: *** [packet-ife.o] Error
1*
what should I do? I have no idea!!!! Thanks in advance
Your problem here is that emem was replaced with wmem starting with Wireshark 2.0. You can read more about wmem in Wireshark's README.wmem file. Naturally, there are plenty of dissectors available in Wireshark's epan/dissectors/ and plugins/*/ directories to serve as excellent examples to help you with the transition.
Related
Using -fsanitizer while compiling programs helps in finding location of memory leaks easily. But how to use this with vscode.
I only know that for compiling a program in vscode through terminal we need to type in g++ file_name.cpp -o executable_name.exe and for running .\program_name
Adding -fsanitizer to this command as an argument does not work for me. How to compile your program using fsanitizer on vscode?
Edit: I have been trying to use it as
g++ -std=c++17 -O2 -Wall -fsanitize=address
tempCodeRunnerFile.cpp -o tempcodeRunnerfile.exe
But this keeps giving me some kind of error:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lasan: No such file or directory
collect2.exe: error: ld returned 1 exit status
This is unrelated to VSCode. The problem is your platform - MinGW traditionally has poor sanitizer support.
Your MSYS2 environment, MINGW64, only supports UBSAN (with stripped-down error reporting, compile with -fsanitize=undefined -fsanitize-undefined-trap-on-error).
There's also CLANG64 environment, which does have ASAN. Install its Clang (pacman -S mingw-w64-clang-x86_64-clang), and compile using clang++ located at C:\msys64\clang64\bin. If you're compiling from MSYS2 terminal, make sure you start the right one: launch it with clang64.exe, or the "MSYS2 Clang x64" shortcut (I don't remember the exact name).
I was wondering if you could help me with some issues and questions I have for developing for the i.MX6 SoloX in bare-metal. I was looking at this link https://community.nxp.com/docs/DOC-106253 and downloaded the files there to use as an example of how to develop bare-metal c code for the i.MX6.
Then I setup my eclipse environment according to this tutorial https://community.nxp.com/docs/DOC-103736 but just the toolchain because I'm not interested in processor expert.
Since I'm working on Linux I didn't installed the Code Sourcery thing, instead I'm working with the gcc-arm-none-eabi which I installed using:
$ sudo apt-get install gcc-arm-none-eabi
And therefore I had to change the cs-rm and cs-make for rm and make respectively.
And I was able to create an eclipse project with the downloaded code and configure the project to make it work, nevertheless, I had the first error:
main.c:8:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
make: *** [cortex_A9/main.o] Error 1
cortex_A9/subdir.mk:24: recipe for target 'cortex_A9/main.o' failed
And I was able to solve it adding "/usr/include" in the include directories at project > properties. But I'm not sure if this is a correct way of solving this error.
After fixing this error I got a new one:
syscalls.c:168:1: error: unknown type name 'caddr_t'
caddr_t _sbrk(int incr)
And for solving that I had to include explicitly the file "/usr/include/x86_64-linux-gnu/sys/types.h" and also I don't know if that is the correct way to solve it.
Now having eliminated those two errors I have the following one:
Building target: imx6-A9.elf
Invoking: Cross ARM C Linker
arm-none-eabi-gcc -mcpu=cortex-a9 -march=armv7-a -marm -mlittle-endian -mfloat-abi=softfp -mfpu=neon -mno-unaligned-access -fno-zero-initialized-in-bss -O0 -g -T "/home/mmalagon/iMX6/MX6SX_hello_MFG/cortex_A9/mx6slx.ld" -nostartfiles -Wl,-Map,"imx6-A9.map" -o "imx6-A9.elf" ./cortex_A9/main.o ./cortex_A9/syscalls.o ./cortex_A9/uart.o
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: cannot find -lg
makefile:42: recipe for target 'imx6-A9.elf' failed
/usr/lib/gcc/arm-none-eabi/4.9.3/../../../arm-none-eabi/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [imx6-A9.elf] Error 1
Which I haven't been able to resolve.
I don't know if this error is a consequence of the way I solved the two previous errors.
Does anybody know how to properly setup eclipse for i.MX6 bare-metal development?
Thank you very much for helping!!
If you want to develop bare-metal code for the i.MX6SoloX without using CodeSourcery then you need to execute this:
sudo apt-get install gcc-arm-none-eabi libnewlib-arm-none-eabi -y
And then choose "Custom (arm-none-eabi-gcc)" at Project>Settings>C/C++ Build in the 'Toolchains' tab.
I downloaded the Libpcap-1.7.4 library . when i want to run libpcap.o and libpcap.so.1.7.4, the following errors appear:
[root#localhost libpcap-1.7.4]# ./libpcap.a
./libpcap.a: line 1: syntax error near unexpected token `newline'
./libpcap.a: line 1: `!<arch>'
[root#localhost libpcap-1.7.4]# ./libpcap.so.1.7.4
Segmentation fault (core dumped)
Could you give me some advice about what I should do?
OS: Centos 6.x
Could you give me some advice about what I should do?
Not try to run libpcap - it's a library, not a program, so you can't run it, you can only link a program with it.
What you need to do is link a program with it, and then run the program.
For example, if you have a C source file named small_sniffer.c, and you want to compile it and link it with libpcap, try
gcc -o small_sniffer small_sniffer.c -lpcap
for dynamic linking and
gcc -static -o small_sniffer small_sniffer.c -lpcap
to link entirely statically
I'm trying to build an 'out of tree' plugin for VLC.
Computer Specs: Intel x64 Ubuntu 12.04
VLC Specs: VLC media player 2.0.8
To tackle this I
cloned the VLC git repository
added my module (just a copy of vmem with some name changes)
added modules info to the autotools
It worked! I can see my module in VLC when I go to tools->preferences->video->output.
I want to do the same thing 'Out of Tree' where I build the module independent of the VLC tree and copy the generated shared object library to a place where VLC can read it and VLC detects it.
I followed the instructions on here:
VLC Out of tree compile
I copied my 'in tree' module to a new directory
Wrote a SConstruct file to build it based off of the instructions from above as well as the instructions on http://wiki.videolan.org/Documentation:VLC_Modules_Loading/
Here is a shortened version of the module:
#define DOMAIN "vlc-nysa"
#define _(str) dgettext(DOMAIN, str)
#define N_(str) (str)
#define MODULE_STRING "nysa-video"
vlc_module_begin()
/* VLC Uses these to identify the module */
set_text_domain (DOMAIN)
set_description (N_("Nysa Video Output" ))
set_shortname (N_("Nysa Video" ))
set_category (CAT_VIDEO )
set_subcategory (SUBCAT_VIDEO_VOUT )
set_capability ("vout display", 1 )
/* Options left out for brevity */
/* Add Callbacks */
set_callbacks (Open, Close )
vlc_module_end()
/* implementation here */
Output
So people don't have to figure out the scons syntax here is the build output:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/nysa_video.os -c -std=gnu99 -Wall -Wextra -O2 -fPIC -fPIC -D__PLUGIN__ -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_THREAD_SAFE -DPIC -I/usr/include/vlc -I/usr/include/vlc/plugins -Iinclude src/nysa_video.c
gcc -o build/libnysa_video_plugin.so -Wl,-no-undefined,-z,defs -shared src/nysa_video.os -L/usr/lib -L/usr/local/lib -lvlc -lvlccore
scons: `install' is up to date.
scons: done building targets.
Results
I do get a file called libnysa_video_plugin.so which I copy into /usr/lib/vlc/plugins/video_output directory
When I run VLC I get a seg fault:
VLC media player 2.0.8 Twoflower (revision 2.0.8a-0-g68cf50b)
Segmentation fault (core dumped)
dmesg | tail prints out:
[141376.468964] vlc[27609]: segfault at 88 ip 00007f06ccd6a4db sp 00007fff029a6310 error 6 in libvlccore.so.5.1.1[7f06ccce4000+db000]
Here is a link to my git repo for this project:
Nysa Video Git Repo
To build you need scons and in the base directory:
to build: scons
to install (installs to /usr/lib/vlc/plugins/video_output): sudo scons install
I found there was a bug in my code
vlc_module_begin()
/* VLC Uses these to identify the module */
set_text_domain (DOMAIN) //THIS SHOULDN'T BE HERE
set_description (N_("Nysa Video Output" ))
I felt bad for posting this question when it was simply a bug so I created a git repo that will hopefully help someone looking to build an out of tree plugin for VLC.
VLC Out of tree Plugin
There are instructions in the readme
Can anybody give me some hints for solving this?
I'm trying to compile "Kinect Matlab" (on Mac OS 10.7), in the compile script is the following line:
mex('-v','-L/usr/lib/','-lOpenNI',[...],Filename);
This is the full command run by mex: (1)
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2011a.app/extern/lib/maci64/mexFunction.map -o "mxNiChangeDepthViewPoint.mexmaci64" mxNiChangeDepthViewPoint.o -L/usr/lib/ -lOpenNI -L/Applications/MATLAB_R2011a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Then I'm getting the following error:
ld: library not found for -lOpenNI
collect2: ld returned 1 exit status
mex: link of ' "mxNiChangeDepthViewPoint.mexmaci64"' failed.
There is most definitely a file at /usr/lib/libOpenNI.dylib.
What kinds of things cause ld to throw this error?
What I tried:
I have tried creating a symlink called libOpenNI.so, like jmlopez suggested, no effect.
Could it be that libOpenNI is a 32bit library, and ld is not seeing it for that reason? Or would the error then be different?
Regarding the point above, it says that the build is "universal x86/x64"
Env vars:
I've tried to add the library to the environment variables using the following command, from the matlab terminal. No effect.
setenv('DYLD_LIBRARY_PATH', [getenv('DYLD_LIBRARY_PATH') ':/usr/lib/']);
In bash:
Just calling gcc as suggested here https://serverfault.com/questions/54736/how-to-check-if-a-library-is-installed gives no problems.
$ gcc -lOpenNi
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
However, if I run g++ first, then gcc as in (1), same error as before. (library not found). How come gcc can find the library, but when matlab adds the stuff in (1) it messes things up?
So, related to what is said above, I started removing all arguments from (1) until I got a different error. I removed the -Wl,-syslibroot, meaning that -syslibroot would no longer be passed to ld, this seems to have fixed it. So -syslibroot is messing up the library search directory! Now to find a way to remove this argument from the mex() call.
Did you trying adding OpenNi to your LIBRARY_PATH ?
export LIBRARY_PATH=$LIBRARY_PATH:/YOUR-PATH/OpenNi
First option: if libOpenNi isn't of the same architecture as the binary you're compiling, the whole compiler suite will likely ignore it. If you did manage to get it to link anyway, it would probably crash. Find a native 64 bit library and link against that.
Second option: I'm not 100% sure on this, but whenever I've tried doing linking on some esoteric linux projects, I start with a .a object archive in the path specified by -L. If it links, then I'll add -fPIC -shared on x86_64 to get it to compile against the shared library. I'm not sure if this will work on OSX: I've never done development on that platform yet.
BOOM! IT WORKS!
Okay, here it is:
The -Wl,-syslibroot option in the gcc call (1) is sending a -syslibroot option to the linker, and somehow that gets prepended to the library search path (even though it shouldn't according to cannot specify root sdk directory with syslibroot when linking)
So, removing this -syslibroot can solve our problem, this can be done in mexopts.sh. Copying matlab's version from the default location:
cp /Applications/MATLAB_R2011a.app/bin/mexopts.sh ~/.matlab/R2011a/
And then changing this line (201):
LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch $ARCHS -Wl,-syslibroot,$SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"
Removing the -Wl,-syslibroot,$SDKROOT argument.
Additionally, I could remove the -L/usr/lib argument from the call to mex, making it simply:
mex('-v','-lOpenNI',['-I' OpenNiPathInclude],Filename);