I am trying to compile a project using the libusb-1.0 library. When i compile from cmd with the following command
gcc -g main.c -o test.exe -lusb-1.0
my program compiles just fine. However if I try to use the Powershell window inside VSC i get this error
gcc.exe: error: .0: No such file or directory
I've run the same code from both terminals.
While I still can compile and run my code, it would be convenient if I could do it from within VSC.
How can i fix this error?
Try with (double) quotes around the -lusb-1.0 parameter.
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.
I have a Beaglebone (Rev: A6) and i want to develop C/C++ program in windows 7 using Eclipse and then transfer executable in the board. But i'm having trouble setting up compiler/debugger/toolchain needed for Beaglebone. Searching the internet only gives me how to setup environment in Linux like installing 'arm-linux-gnueabi', setting up the paths to 'includes' etc. I need a step by step instruction to set up the environment in Eclipse in a windows machine. Can anyone help ?
I have tried these steps:
1. I have GNUARM installed on windows.
2. On eclipse IDE i open a C++ project with Corss GCC.
3. From project -> properties -> C/C++ build -> settings i add 'arm-elf-' to every cross compiler command.
4. From the GNUARM installation directory i add few path to '.../include/' in the 'C++ General -> paths and symbos'.
my 'build all' shows something as below:
10:32:20 **** Build of configuration Debug for project h ****
make all
Building file: ../src/hello.cpp
Invoking: Cross G++ Compiler
arm-elf-g++ -I"C:\GNUARM\include\c++\4.1.1" -I"C:\GNUARM\include\c++\4.1.1\arm-elf" - I"C:\GNUARM\include\c++\4.1.1\backward" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP - MF"src/hello.d" -MT"src/hello.d" -o "src/hello.o" "../src/hello.cpp"
Finished building: ../src/hello.cpp
Building target: h
Invoking: Cross G++ Linker
arm-elf-g++ -L"C:\GNUARM\lib\gcc\arm-elf\4.1.1\include" -o "h" ./src/hello.o
Finished building target: h
10:32:23 Build Finished (took 2s.967ms)
It is simple 'Hello world' printing program. From the project explorer 'Debug->src->hello.o -[arm/le]' i copy it and when run on beaglebone with
chmod ugo+x hello.o
./hello.o
-sh: ./hello.o: cannot execute binary file
the above massage is printed. I don't know what i did wrong. Perhaps the ARM environment in eclipse is set up incorrectly.
Isn't hello.o the pre-linked object file (just the compiled content of hello.cpp)? It doesn't contain the startup code or any library functions. The linker adds those to produce the final output.
Don't you want to run the linker ouput file h (which should already be executable)?
i got my answer here. http://www.acmesystems.it/foxg20_eclipse_windows_c. CodeSourcery was the toolchain that i was looking for and this also explains how to setup the corss compiling environment.
I am trying to debug clang using eclipse. I have put a break point in clang/lib/lex/preprocessor.cpp at the preprocessor's constructor.
I have set a "test.c" file as an argument in the debug configurations.
Went to Run-> Debug As-> Local C/C++ Application.
It asked "Choose local application to debug". I chose "clang" and clicked OK.
It started building the code. build completed.
Stopped at main() in the debug window. (No source available for main())
After some step overs, it says "terminated: gdb Debugger (Exited. Exit code=255)"
I am not taken to the clang code (preprocessor code). can someone please tell me how to debug the clang code.? I want to see the code flow in clang. and how clang is constructing the AST.
Clang binary in fact contains two apps: driver and compiler frontend itself. The latter is executed via -cc1 cmdline option. So, just add -v to clang command line to see the actual sequence of tool invocation, grab the frontend cmdline (the one containing -cc1) and use this cmdline for debugging.
Had the same problem - you are missing the -g flag (enable debug info) when you are building your binaries.
When running the cmake run it with the CMAKE_BUILD_TYPE option:
cmake -G "Eclipse <CDT_Version> - Unix Makefiles" -D_ECLIPSE_VERSION=<eclipse_version> -DCMAKE_BUILD_TYPE=Debug <llvm_source_path>
example :
cmake -G "Eclipse CDT4 - Unix Makefiles" -D_ECLIPSE_VERSION=4.4 -DCMAKE_BUILD_TYPE=Debug ../llvm/
hope that this helps.
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);