I have been trying to install GDB on my new Macbook Pro running Mountain Lion. I have installed using both Macports and Brew, I have successfully code signed the binaries, but in both cases when I try to debug a simple "Hello World" application I receive a whole load of warnings similar to:
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c10.o': can't open to read symbols: No such file or directory.
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c16.o': can't open to read symbols: No such file or directory.
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c4.o': can't open to read symbols: No such file or directory.
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c8.o': can't open to read symbols: No such file or directory.
Now, my username is not gkhanna and there are no users registered on the laptop by that name. The versions of gdb I have installed are 7.6.0 and 7.6.1. Could anybody explain what has happened here and how to point GDB to the correct path?
To quiet the warnings, you can strip the debugging symbols that can't be read (since they point to files not on your machine and really shouldn't have been left in there in the first place.)
First, figure out which libgfortran dylib your gcc is using with otool -L a.out, then strip the debug symbols from that libgfortran dylib with strip -x path_to_libgfortran_dylib.
Related
I'm working on touching up homebrew's (OS X package manager) llvm formula. Unfortunately, something about the parts I added broke the build in a way I just cannot figure out.
tl;dr ld asks for a library containing a _wordexp symbol for iOS simulator, and I have absolutely no clue where it is, if it exists
Compilation consistently fails for me when the compiler is attempting to link the address sanitizer dylib for iOS Simulator.
Reproduction steps (OS X only as far as I know, don't have *nix systems handy):
install homebrew if it isn't already installed
replace homebrew's llvm formula with the WIP one above
Run brew install llvm --with-clang --with-lldb --verbose --debug
wait for the build to fail and ask you what to do
Drop into a debug shell
cd to projects/compiler-rt/lib/asan/CMakeFiles/clang_rt.asan_iossim_dynamic.dir
add the following line to link.txt
-Wl,-syslibroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
go back up to asan
Run make
At this point on my machine, something like this pops up:
Undefined symbols for architecture x86_64:
"_wordexp", referenced from:
_wrap_wordexp in asan_interceptors.cc.o
substitution_wordexp in asan_interceptors.cc.o
(maybe you meant: _wrap_wordexp)
ld: symbol(s) not found for architecture x86_64
I thought that it was just a matter of adding another folder to the linker search path. Turns out it isn't that simple:
wordexp.h is in <path-to-iPhoneSimulator.sdk>/usr/include, but running
find . -type f -name "*.dylib" -print0 | xargs -0 nm | grep -n "T _wordexp" -B <large number> | less
in Xcode-beta.app showed that the only .dylibs in Xcode that exported a _wordexp symbol were in the WatchSimulator.platform folder
Running the same command in /usr showed that 3 libraries in /usr/lib/system exported _wordexp (libsystem_asl, libsystem_c, and libsystem_blocks), but the linker doesn't seem to care when I add /usr/lib/system to the search path even when the code is the x86_64 code it wants, and the corresponding dylibs I found for other platforms didn't contain _wordexp
Googling about about this particular symbol missing turned up mostly stuff about Apple implementing wordexp() with Perl
I think I remember seeing something in the llvm-dev mailing list archives about *BSD/OSX not implementing wordexp, but the header file is definitely there, wordexp() shows up in the manpages, and the functions declared in the header file seem to work just fine when compiling for OSX
The symbol is not in the libc++(abi) dylibs compiled earlier in the build
Every other part of the build compiles just fine except for the asan folder and its parents
What am I missing? Given that this error does not seem to be particularly common, there could be a chance it's my machine, but I'm hoping the chances are pretty low, because I wiped and reinstalled my computer this weekend.
(OS X 10.11, Xcode/CLT 7.1, mid-2012 Retina pro)
If more info is needed I'll be happy to provide it.
Edit 1: Simplified link.txt fix. Turns out setting sysroot for clang++ doesn't do so for ld
Turns out the error was a result of the way homebrew processed compiler flags. That and a few other problems have been fixed since, so this probably isn't too useful any more.
For those curious about how exactly this broke, homebrew tries to change compiler flags to suppress warnings and create a more consistent building experience. One of these changes was to remove any -isysroot or -system flags, because that was added by homebrew itself at a later stage. Unfortunately, homebrew assumed that only the OS X SDK would be used, so when the build expected to build something with the iPhone simulator SDK it was pointed to the OS X SDK.
I'm trying to debug a Fortran 95 program using gdb 4.8. When I encounter a breakpoint (or the error I'm trying to debug), I cannot print any information on local variables using the info command. I also get a No symbol tape information available error when running bt full.
I don't believe this is related to the version of gdb as I first tried installing the version from Homebrew and got the same error. I then removed the Homebrew installation and compiled and installed the latest available version of gdb from source. My Fortran file is compiled with the -g flag and the -fbacktrace flag and has no explicit optimization flag, but I have attempted to compile with -O0, -O1, -O2, and -O0. All give the same error.
Possibly related is the fact that, upon running the code, I get loads of warnings. Here is a small excerpt:
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_c8_i4.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_c8_i8.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i16_i16.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i16_i4.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i16_i8.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i4_i16.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i4_i4.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i4_i8.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i8_i16.o': can't open to read symbols: No such file or directory.
I have gcc installed by Homebrew but which gcc returns /usr/bin rather than /usr/local/bin, so this is is probably the default Mac install. /private/tmp/gcc-dmSW1S/ does not exist. Can provide any other information needed.
You are using a sufficiently ancient version of gdb that it won't be able to read debug symbols from your objects compiled with gcc 4.9. The 4.x version of GDB are at least 15 years old and and date back to the gcc 2.95 / egcs era of compilers. Numerous ABI and debug symbol changes make gdb 4.x unsuitable for debugging objects compiled with GCC 4.9.
For objects compiled with GCC 4.9 and default debug symbol output (DWARF4 iirc), you'll want GDB 7.5.1 or newer. The current GDB release is 7.9.
Trying to debug an application written in Qt on mac (10.6.8). Qt 4.8.6, QtCreator 3.2.0, I set up the debugger System GDB at /usr/bin/gdb and compiler gcc-4.2
I want to debug the code...
I get in the application output window
Debugging starts
Debugging has failed
Debugging has finished
(and no breakpoints were hit, nothing has started in code)
I opened the debug log window, and the only suspicious things I saw were
....
111^error,msg="Undefined command: \"python\". Try \"help\*.*
NOTE: ENGINE SETUP FAILED
State Changed From EngineSetupRequested(1) to EngineSetupFailed(2)
HANDLE RUNCONTROL FINISHED
.....
On the left, some of the commands had
109-interpreter-exec console "python sys.path.insert(1, "/Volumes/QtCreator/..."
110-interpreter-exec console "python sys.path.append("/usr/bin/data-directory/ python)"
111-interpreter-exec console "python from gdbbridge import *"
I checked that python is installed... i can type python from anywhere and get its command prompt so it is on system path...
I read something about having to sign a fsf debugger but the one I am using is not a fsf debugger ?
What can I do to debug my apps in macx ?
Edit: Tried gdb from command line, with the app as argument
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
...
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols for QtSvg.framework/Versions/4/QtSvg (file not found).
warning: Unable to read symbols from "QtSvg" (not yet mapped into memory).
warning: Unable to read symbols for QtGui.framework/Versions/4/QtGui (file not found).
warning: Unable to read symbols from "QtGui" (not yet mapped into memory).
warning: Unable to read symbols for QtCore.framework/Versions/4/QtCore (file not found).
warning: Unable to read symbols from "QtCore" (not yet mapped into memory).
warning: Unable to read symbols for QtNetwork.framework/Versions/4/QtNetwork (file not found).
warning: Unable to read symbols from "QtNetwork" (not yet mapped into memory).
Reading symbols for shared libraries .
... some warnings that .o is more recent than .dylib in dependent libs... but that I don't have to step into so I don't care...
...
warning: Could not find object file "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/crt3.o" - no debug information available for "darwin-crt3.c".
.... done
So I type run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff83872c00 in strlen ()
I don't know where that is (I do but really can't see it) or if it is an actual string pointer or something else...
I don't know where the breakpoints would be, the entire source is very long and contains lots and lots of files so I really don't know how I can do it with gdb from command line...
But it seems that it did get started, without complains about python ?
The warnings at start - could that mean that there is still hope, that it is possible to somehow configure gdb to run with Qt if it learns about its libraries ?
By the way... searching for the missing libraries...
QT 4.8.4 debug libraries not found on Mac OSX
I have tried to replace my debugger (in Qt) using lldb and qmake - in both cases I got an error "Unable to create a debugger engine of the type 'No engine'"
Edit: Another suggestion I read about is to recompile Qt Creator Binaries to add debug symbols... I hope that is not what I have to do because
"Note: With Qt Creator 3.2 we drop support for OS X 10.6 (Snow Leopard). The technical reason for this is that Apple does not support any kind of C++11 on that OS version. Of course that does not affect on which platforms you can run your Qt applications on. But it is not possible to run the Qt Creator 3.2 binaries on 10.6, and it also is not possible to compile Qt Creator 3.2 on 10.6 with the tool chains provided by Apple." (from release notes)
Update: I was able to find the cause of the error above (the KERN_INVALID_ADDRESS) by placing a zillion qDebug() statements... Though that was not what I am trying to accomplish, one error out of many.
I still have lots of errors... Attaching a debugger would be wonderful. I have listed the required libs for the program - they seem to exist. Not sure if they are "debug" or "release" libraries. .... But I am not trying to step through the Qt sources, so why would it matter if I have debug symbols for them ? And if they were "release" type libs, then my whole program, build in "debug", would not execute or even fail to build ? Since I am building my code in "Debug" mode and it executes, the libraries must be correct, right ?
So confusing...
QtCreator 3.2 (and a few versions before that) requires a GDB that has Python scripting enabled (or LLDB, or CDB on Windows). On Mac, Apple's GDB doesn't have Python scripting, and therefore cannot be use with Qt Creator. FSF GDB works for some projects on Mac, but in general LLDB is preferable there.
Your "GNU gdb 6.3.50-20050815 (Apple version gdb-1518)" is such an non-Python-enabled Apple build.
I just upgraded to Mountain Lion OSX 10.8 and along with that I foolishly upgraded to Xcode 4.4.
However, after this upgrade "make" is gone and things like gcc -v also do not work.
This is a big thing since I am writing my phD and I rely on make to compile my LaTeX docs...
Downloading the "command line tools"
http://adcdownload.apple.com/Developer_Tools/xcode_4.4_gm_seed/cltools10_8gmseed6938077a.dmg
Is apparently not allowed for non-paying dev accounts.
What kind of foolishness is this?
They're not gone, they've just been relocated to inside Xcode's app bundle. This is actually nicer as it allows side by side installs of different XCode/SDK versions.
You can find them at: /Applications/Xcode.app/Contents/Developer/usr/bin
Also check out the xcode-select tool to allow you to choose the current active toolchain path.
I did the same thing as you this morning. To fix it, I just added the following to my ~/.bash_profile:
export PATH=$PATH:/Applications/Xcode.app/Contents/Developer/usr/bin
Interestingly,
The "Downloads" interface inside Xcode 4.4 seems to point to the following location for downloading the "Command line tools":
http://adcdownload.apple.com/Developer_Tools/xcode_4.4_gm_seed/cltools10_8gmseed6938077a.dmg
Judging by the "gm" reference in that URL I think this is an error. Without a paying dev account you cannot download this...
I issued the export PATH command, and then tried to compile hello.c, but compilation fails because it does not find the file stdio.h. So, I changed the include statement to specify the full path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/stdio.h, but then compilation fails because it does not find 3 other .h files.
export PATH=$PATH:/Applications/Xcode.app/Contents/Developer/usr/bin
cat hello.c
#include <stdio.h>
int main()
{
printf("Hello World \n");
}
gcc hello.c -o hello
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function ‘main’:
hello.c:4: warning: incompatible implicit declaration of built-in function ‘printf’
gcc hello.c -o hello
In file included from hello.c:2:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/stdio.h:64:23: error: sys/cdefs.h: No such file or directory
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/stdio.h:65:26: error: Availability.h: No such file or directory
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/stdio.h:67:20: error: _types.h: No such file or directory
Old thread, but I was just looking for this myself in Xcode 4.6:
Install Xcode
Go to Preferences->Downloads->Components and there will be an "Install" button next to "Command Line Tools"
I am getting started with using MEX files for MATLAB (R2012a) compiled from C code (using XCode 4.3) on my Mac (running OSX 10.7.3, Lion). I have already installed the MATLAB provided XCode patch which configures MATLAB to use the new llvm-gcc compiler under XCode 4.2+, but I am still getting the following error attempting to compile the example file using mex timestwo.c:
/Applications/MATLAB_R2012a.app/extern/include/matrix.h:852:20: error: stdlib.h: No such file or directory
In file included from timestwo.c:1:
/Applications/MATLAB_R2012a.app/extern/include/mex.h:161:19: error: stdio.h: No such file or directory
The compilation then breaks
mex: compile of ' "timestwo.c"' failed.
Error using mex (line 206)
Unable to complete successfully.
Clearly, the compiler can't find the standard library header directory, but what do I need to change to successfully compile?
Ah, found it!
The MATLAB provided template uses /Developer/... for the SDK location, but this changed under XCode4.3 to live under the XCode.app. To fix things, I had to edit my ~/.matlab/R2012a/mexopts.sh file to set the SDKROOT directory to the new location.
To do this, search for SDKROOT in the mexopts.sh file and change it to read:
SDKROOT='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/'
Note, I chose the 10.7 sdk b/c I am on Lion. Use 10.6 if you are on Snow Leopard
I am running Mac Mountain Lion and Matlab R2012b, and the following solution worked for me: Matlab 2012a Mex to work with Xcode 4.5 on Mountain Lion
To be precise,
I was getting the following errors:
error: stdio.h: No such file or directory
error: stdlib.h: No such file or directory
error: math.h: No such file or directory
So what I did to solve this issue:
I installed Xcode with Command Line Tools, and then edited the file "/Applications/MATLAB_R2012b.app/bin/mexopts.sh" by:
changing CC from gcc-4.2 to llvm-gcc-4.2
changing CXX from gcc-4.2 to llvm-g++-4.2
setting SDKROOT to '/'
Then I ran "mex -setup" in MATLAB, chose number 1, and chose y to overwrite the old /Users/insertyournamehere/.matlab/R2012b/mexopts.sh
That solved it :)
You will find valuable information here: http://www.mathworks.fr/support/solutions/en/data/1-FR6LXJ/