I am using OSX 10.8.2 and gdb 6.3. I have to use both xcode 4.6.1 and xcode 3.
I have a simple c executable for which i am trying to attach gdb through command line. But i am not able to give break points. As soon as the gdb is attached i am getting the below lines.
unable to read unknown load command 0x2b
unable to read unknown load command 0x80000022
unable to read unknown load command 0x24
unable to read unknown load command 0x2a
I goggled it out and found that gdb 6.3 has few bugs for which above thing might be happening. so i thought of updating the gdb to 7.6. Even this is not happening.
Steps i did to install gdb 7.6
./congigure
make
make install
make is ending with below lines
make[8]: Nothing to be done for `all-am'.
make[1]: Nothing to be done for `all-target'.
make install with below lines
make[11]: Nothing to be done for `install-data-am'.
make[1]: Nothing to be done for `install-target'.
I want gdb which is supported by xcode 3,4.6 as well as in command line. Please help to resolve this.
They're just warnings, you're fine to ignore them. The gdb binary you're using didn't include the definitions of these load commands (LC_DYLD_INFO_ONLY, LC_VERSION_MIN_MACOSX, etc see /usr/include/mach-o/loader.h) and it's complaining about them when it parses the Mach-O binaries with them included. The gdb included in Xcode 4.6 will handle these without warning, fwiw.
As I can figure out with make command output your program is compiled and not changed. So you have to make clean your code and try again. Make sure that you are compiling the code with -g parameter of gcc to link the symbol table of C to the executable, in order to give to gdb the necessary parameters for debugging. So, you must to have a look at makefile.
Related
I've tried compiling an SDL2 program on windows using mingw gcc in Code::Blocks, but the only way I can get the produced binary to work is by stripping the symbols with the -s option. Even with just a simple printf program, but only when SDL.h is included.
What is going wrong and how can I fix it?
Produced output differs depending on how the binary is run.
Using the terminal I get:
Program 'main.exe' failed to run: The specified executable is not a valid application for this OS platform
Using Code::Blocks to build and run, the produced binary runs, but without any output and exits immediately with:
Process terminated with status 32760
Looking up the status code produces no results, both in mingw and SDL2.
Trying to compile with -static causes a bunch of output with ld returned 1 exit status and Dwarf Error: Can't find .debug_ranges section.
This seems to imply that debug info is missing from the linked dll file as I understand it.
SDL2 is included and linked from the extracted SDL2-devel-2.24.0-mingw folder from the libsdl github releases.
The same errors can be reproduced by creating a SDL2 project with Code::Blocks and compiling the given code in debug and release, since only the release strips the symbols it runs fine, but the debug build does not. Enabling the -s option in debug produces a working binary.
Edit: Compiling SDL2 from source seems to have fixed the issue, so this seems to only be a problem with the precompiled binaries downloaded from the release page. I'm assuming it was because of the missing debug symbols, but it would be appreciated if anyone can confirm that this was the case and explain why stripping symbols creates a working binary?
Edit 2: The main problem seems to be with the outdated mingw compiler included with Code::Blocks which is on version 8.1.0. Using a more recent version of mingw64 such as 12.2.0 from mingw-w64 also fixes the issue.
Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.
I am trying to compile a C code on Oracle Linux 7.2 which is hosted as VM on windows 10.
Name of file run: configure
Name of log file: confg.log
Error where I am stuck
gcc: error: unrecognized command line option '-V'
As per my understanding of the code structure so far, there is a file named configure which is having compilation related commands and this file generates Makefile.am which further generates Makefile.in and at last Makefile.
Please help me in solving the error and also let me know if my understanding about the configure and makefiles is incorrect
configure scripts explore the environment in which a program is to be built. They then accordingly adjust tools called, options used and libraries linked, among other things. Some of the information is obtained by trying to execute programs with certain options; failure of a program to run is the intended way of obtaining the information that the given program is not available or does not take those options. Therefore it is not necessarily an error if one of the things doesn't work and produces an error; it may be one of the legitimate outcomes, and the (error, here) exit code of the compiler will be used to modify the Makefile accordingly — for example by omitting -V ;-).
Does the configure script actually stop there, or are you just observing the error in the log file? If you search for gcc -V on the web you'll find examples of configure scripts failing actually later (for unrelated reasons) which have the same "-V error" line in it. Could that be the case? I would assume that errors which actually cause configure to stop and not produce a Makefile should be visible on the command line, not only in the log file.
As an aside it is worthwhile to run ./configure --help and look through the options. Some may improve the build process or the result; for example you can usually tell configure that you are using gcc, gnu ld and so on, or that you don't need certain features (like X25 ;-) ).
You should look into the makefile of your project, identify where the misspelled -V option is and replace it with -v (lowercase). As pointed out by others in the comments -V is not a compiling flag, but gives back the compiler's version.
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 just started coding in C, and ran someone else's Makefile with the default C compiler set to gcc. I am on Mac OSX 10.8 Mountain Lion and I believe I installed the compiler with "XCode Command Line Tools." After running "make" on command line, I get these annoying .dSYM files for each program. I read that these are debug files, but are they really necessary? Is there any way to prevent them from being generated from command line?
The -g flag to GCC will generate debug symbols. You may simply remove that flag from CFLAGS.
Yes, the dSYM files are necessary. Specifically, they contain the symbol tables that are included within Xcode debug builds; release builds put the symbols in this separate file. If you ever need to analyze a stack trace from a release build you will need this. And make sure you don't lose the files, because doing the build again, even if the source is absolutely the same, won't produce a usable dSYM file. Each build is given a UUID and that changes with each build, even if the source has not changed. (I guess it includes a timestamp or even a random number.)
If you throw away the dSYM files, then if you suddenly find your app crashing a lot, you may be sorry.
They're only necessary if you need to interpret locations in stack traces within a crash report.