I'm trying to debug a new Janus plugin using Netbeans IDE 8.0.1. It hits my breakpoints OK but when trying to step through the code it's jumping all over the place and I'm frequently seeing 'optimized out' when trying to inspect variables. I'm fairly sure this is because the code has been built with optimization enabled.
Assuming this is the problem, how do I rebuild it with optimizations disabled please? I've tried running configure with 'CFLAG=-O0 -g' followed by a clean & build, but I'm still getting the same problem. The Janus configure file has a couple of promising looking environment variables, JANUS_CFLAGS and PLUGINS_CFLAGS. However, when I try to set these to '-O0 -g', clean and make I get a compilation error:
fatal error glib.h: No such file or directory
Any suggestions would be appreciated.
If you change the compilation from the make file(not from the command line), it should work to make the non-optimamized.
Specifically, the line CFLAGS = -g -O2 should be changed to CFLAGS = -g -O0. I know this works with GDB(and consequently eclipse) and SHOULD work with any other debugger.
Related
I have downloaded the well-known linuxptp source code (C language) from:
git clone git://git.code.sf.net/p/linuxptp/code linuxptp
It is a makeFile project which I could successfully run from command line, however the problem appears when I try to import it to Eclipse:
File > New > Makefile project with existing code
I can successfully build it and run it but I couldn't debug or force it to stop at a break point. I keep getting the message (No source available for "main() at 0x401eb5").
I tried to reinstall Eclipse IDE for C/C++ Developers from the official website but it didn't work.
I think it is useful to mention that:
- the source code I'm using contains different files with main() function
- Eclipse debugger runs successfully on projects created on Eclipse from scratches
Any ideas?
thanks.
You should create some debugging launch configurations for your different executables in the project.
Also be sure that the Makefiles include -g option when compiling to produce the required debugging information.
Edit:
Add this lines to your Makefiles:
CFLAGS += -g
CXXFLAGS += -g
I have the MinGW install previously working fine with MSYS. They are installed properly and functioning just well.
I installed the PortAudio library and did the install and got the success message after:
./configure
make
make install
When I try to compile samples:
c:\c>gcc patest_mono.c -o pa.exe
patest_mono.c:50:23: fatal error: portaudio.h: No such file or directory
#include "portaudio.h"
^
compilation terminated.
I'm new. I have a feeling I might be doing something fundamentally wrong with the way I'm trying to create the exe from compiling. It's been somewhat of a puzzle quest so far, but I've tried to figure it out and think I am close but completely missing something.
PATH variable ?
In the PortAudio MinGW build instructions I noticed
"The above should create a working version though you might want to
provide '–prefix=<path-to-install-dir>' to configure. "
I've tried adding C:\MingW\PortAudio into the user path. Doesn't work.
I've also tried running the commands in Bash and they come back with an error message "No Rule to make target 'paexpink'" either with the make command, and with gcc .c -o .exe I just get the same error message as compiling straight from the cmd prompt.
I found another source on stack overflow thread with no answers, but the user had commented that http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyaudio provided them a solution but I tried installing the 5 cpython binaries and under the assumption I did it right, it didn't work either.
Thanks for your help,
Julian
To build and install portaudio, you need to add -prefix=/c/<"path to base of the MinGW directory"> to the ./configure line.
For example: ./configure -prefix=/c/MinGW/
then continue the installation by doing
make
After that, do the
make install
and that should install the portaudio files into MinGW.
After it has finished installing, you need to add -lportaudio to the compile command whenever you compile any programs that you want to use PortAudio in.
For example: gcc -o test test.c -lportaudio
I just figured out how to do this today, so I may have accidentally forgotten a few steps.
I'm building a plugin on Mac OS X using Eclipse CDT, which streams some data via libwebsockets to a browser websocket connection. The compilation process works fine, and I'm able to run my plugin in X-Plane and see data coming in on Google Chrome as expected.
I want to setup debugging with GDB, but I've been pulling my hair for about a week now without any success. I've created a launch configuration in Eclipse CDT to Attach to Application, but every time the debug session is supposed to start, I just get the following in the Eclipse debug perspective:
When starting the Debug, Eclipse shows me a popup list of running processes, and I select X-Plane, but when starting, it simply shows that the thread is suspended.
I've set up the launch configuration as follows:
As an alternative, I tried setting up a project using a makefile, which can be seen here:
https://gist.github.com/josefvanniekerk/690ad22160789c724490
The gcc and linker invocations from Eclipse CDT look as follows:
Building file: ../src/XPWebSocket.c
Invoking: GCC C Compiler
gcc -DAPL=1 -DIBM=0 -DLIN=0 -DXPLM210 -I../lib/xpsdk_v213/CHeaders/XPLM -I../lib/libwebsockets/lib -O3 -g3 -Wall -c -fmessage-length=0 -fvisibility=hidden -MMD -MP -MF"src/XPWebSocket.d" -MT"src/XPWebSocket.d" -o "src/XPWebSocket.o" "../src/XPWebSocket.c"
Finished building: ../src/XPWebSocket.c
Building target: xpwebsocket.xpl
Invoking: MacOS X C Linker
gcc -L../lib/libwebsockets/build/lib -F/{...omitted...}/Projects/xplane/XPWebSocketLib/lib/xpsdk_v213/Libraries/Mac -framework XPLM -shared -o "xpwebsocket.xpl" ./src/XPWebSocket.o -lwebsockets
Finished building target: xpwebsocket.xpl
I've made double sure that I've passed the -g option to enable debugging, but I just can't get this working.
I've tried pointing the C/C++ Application to /Applications/X-Plane/X-Plane.app/Contents/MacOS/X-Plane, changed it to Debug/xpwebsocket.xpl, tried pointing it to the .xpl file inside the X-Plane Resources/Plugins folder, quite frankly, I have no idea what I'm supposed to do to get debugging to work with X-Plane + GDB.
I've started reading up on trying to establish a GDB debug session from the command line, maybe if I understand that process, I can get around to get Eclipse to work. But who knows how many days of reading up that's going to involve.
Can anyone please offer some advice?
More info just in, GDB trace in Eclipse CDT is showing the following (just the error bits):
033,165 &".gdbinit: No such file or directory.\n"
033,165 13^error,msg=".gdbinit: No such file or directory."
037,222 19-target-attach --thread-group i1 197&
037,223 19^error,msg="Asynchronous execution not supported on this target."
After turning off: "Non-stop mode" in CDT, getting the following:
527,581 18^error,msg="Unable to find Mach task port for process-id 197: (os/kern) failure (0x5).\n (\
please check gdb is codesigned - see taskgated(8))"
Guessing I need to codesign X-Plane executable.
I managed to sort this out by signing gdb using the following guide:
http://ntraft.com/installing-gdb-on-os-x-mavericks/
However, fixing the above only reveals that there's possibly a LOT wrong with GDB on Yosemite.
Maybe I'm missing something obvious since I searched the internet for quite a while but could not find a solution for the following problem:
I'm using Eclipse Kepler SP2 (Build id: 20140224-0627) with CDT and MinGW as compiler backend. Debugging C code with gdb worked great up until today (at least I noticed the problem today).
Now I get the following error message when i want to start a progam in the debugger:
Error in final launch sequence
Failed to execute MI command:
-file-exec-and-symbols C:/[...]/Debug/test.exe
Error message from debugger back end:
"C:\[...]\Debug\test.exe": not in executable format: File format not recognized
The program runs nicely and so I thought I might have screwed up some settings. But when I tried to debug an old program, everything worked until I recomplied the old program -> same problem. If I ask the C-wizard to create a new "Hello World" ANSI C application with MinGW, the same problem occurs.
The compile commands which were used are
gcc -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\test.o" "..\\src\\test.c"
gcc -o test.exe "src\\test.o"
I did not update my MinGW in between, but updated Eclipse.
Do you have any pointers on where to look for the problem?
Edit: I just checked the binary type: My old projects are all [x86/le], the newly compiled ones are [amd64/le]. This should be a trace.... Will update posting according to progress.
Edit2: argh I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
I'll post this as answer, too. Heading and tags have been updated to point to this issue more directly.
I installed strawberry perl a few days ago, and the installer has changed the environment variable MINGW_HOME in origin BUILD SYSTEM to c:\strawberry\c and this screwed up my builds. Resetting it to my c:\MinGW solved the issue.
BTW: This happened, because strawberry added c:\strawberry\c to the PATH in front of my custom c:\MinGW and eclipse adds those to the BUILD SYSTEM variables.
It should be a parser problem, what is your binary parser under Project/Properties/Build/Settings ?
Check Project->Properties ->C/C++ Build ->environment and path for MINGW_HOME
make sure you have right gdb version (by checking under debug Configuration ->environment).
I'm currently building on Windows 7 and am trying to get my debugger to step through my code. The problem is that, while I have my build configuration set to debug, and my CONFIG variable to set to debug in my QMake file, it still doesn't work.
Here is my QMake file:
TEMPLATE = app
CONFIG += console debug
CONFIG -= qt
QMAKE_CXXFLAGS += -g -gdb
SOURCES += main.c \
Triangle.c \
GlutTesting.c
HEADERS += \
Triangle.h \
Includes.h \
GlutTesting.h
LIBS += -lSDL -lopengl32 -lfreeglut
Note that it's actually written in C and compiled as such (all of the files are native C code, compiled with MinGW).
The issue is that everytime I start, even if I set a breakpoint, the code literally just zooms through it to the end of the applications current setting and stops there. It's almost impossible to actually debug my applications now.
What is wrong here? Everytime I Google I just find something about "adding debugging symbols", which is easy to do in Linux, but in Qt Creator it seems quite the PITA to get done properly (unless I'm just missing something totally simple).
Faced the similar problem on Linux (Fedora 16) using Qt Creator 2.5.0
It turned out that gdb started in my home directory and could not (I don't know why) load debugging symbols of a library being debugged. Whenever I force gdb to start from directory where the library binary file is placed (in Qt Creator it is done through additional debugger startup commands in Tools->Options->Debugger->Additional Startup Commands: just make "cd" to the directory with binary file) everything works fine.
One more solution is to set the environment variable LD_LIBRARY_PATH to contain full path to the directory with binary. In Qt Creator it is done in Project->Run Settings->Run Environment.
In order to check that debugging symbols have been loaded properly open gdb log via Window->Views->Debugger Log and type the command "info shared".
This worked for me under Linux, and I'm not sure if it'll work under Windows but here it goes anyway:
in the .pro file, I added the line:
CONFIG += debug
This enabled debugging within the QT system. Then i added the following:
QMAKE_CXXFLAGS += -O0 -g -ggdb
The -ggdb is for the gdb support. And the O (letter O) 0 (number zero) to be no optimisation - to prevent the compiler from optimising out variables. This gives me the backtraces i need with all the symbols when debugging under Linux. This is a fairly standard debugging compiling option across the board with gdb. But it may already be covered by the debug option in CONFIG.
Under Linux i rebuilt the project too:
make clean
make
But for Windows, if you're using Visual Studio, you might need to do a rebuild. I don't know what your compilation toolchain is.
I know you're using Windows, and it might be worth trying these things in case it works under Windows too. However, even if it doesn't work under Windows, it could be useful for someone searching for how to do this under Linux, so I think this is a valid answer, even though it may not specifically answer this particular question.