Missing C++ header <__debug> after updating OSX Command Line Tools 6.3 - c++

After updating to Command Line Tools 6.3 from the App Store, programs including <vector> or <iterator> which internally include <__debug> will cause file not found error as follows. The cpp is nothing interesting but includes in one of the included headers.
c++ -O3 -I/Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers -L/Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/build/binaries/clusterStaticLibrary /Users/farleylai/Documents/dev/git/ESMS/Optimizer/build/StreamIt/FIR/511/512/combined_threads.cpp -o streamit -lcluster -lpthread -lstdc++
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/build/StreamIt/FIR/511/512/combined_threads.cpp:9:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/node_server.h:22:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/thread_info.h:20:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/connection_info.h:19:
/Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/socket_holder.h:43:25: warning: delete called on 'mysocket' that is abstract but has non-virtual destructor
[-Wdelete-non-virtual-dtor]
if (!is_mem_socket) delete sock;
^
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/build/StreamIt/FIR/511/512/combined_threads.cpp:9:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/node_server.h:22:
In file included from /Users/farleylai/Documents/dev/git/ESMS/Optimizer/../StreamIt/src/cluster/headers/thread_info.h:26:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/vector:265:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__bit_reference:15:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/algorithm:641:10: fatal error: '__debug' file not found
#include <__debug>
^
Any ideas to fix this?
I don't expect to specify any additional C++ flags.
Thanks.
PS: MacBook pro on OSX 10.10.3
Updates:
The issue is verified by Apple on their developer's forum. In Command Line Tools 6.2, the inclusion of __debug is conditionally guarded as follows but not in 6.3.
#ifdef _LIBCPP_DEBUG
# include <__debug>
#else
# define _LIBCPP_ASSERT(x, m) ((void)0)
#endif
And libcxx people talked about removing the guards of __debug here. It feels like __debug never exists on OSX.

Downgrade the Command Line Tools to 6.2 via Apple's Developer Download Page.
Be careful to download the correct version for your OS X:
OS X 10.10 commandlinetoolsosx10.10forxcode6.2.dmg
OS X 10.9 commandlinetoolsosx10.9forxcode6.2.dmg
This works because the inclusion of __debug is conditionally guarded as follows in Command Line Tools 6.2 but not in 6.3.
#ifdef _LIBCPP_DEBUG
# include <__debug>
#else
# define _LIBCPP_ASSERT(x, m) ((void)0)
#endif
In my opinion this is the safest way, because:
You don't compromise your toolchain
You can easily upgrade via the App Store when Apple fixes the issue
If you add a file manually you have to delete it later or more problems could occur
Update - 21.04.2015
Problem fixed by Apple.
After installing Command Line Tools 6.3.1 everything works as expected!

Temporarily create the missing __debug file where _LIBCPP_ASSERT is defined as in Command Line Tools 6.2 for OS X.
echo '#define _LIBCPP_ASSERT(x, m) ((void)0)' | sudo tee -a /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug > /dev/null
Remove the temporary file after the build finished.
sudo rm /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug

Warning!!! This is a hack, use at your own risk!!! This work-around is only meant as a temporary fix until Apple provides an update to the command-line tools.
OK, here we go: Create the file yourself and put the following content into it:
#ifndef _LIBCPP_ASSERT
#define _LIBCPP_ASSERT(...) ((void)0)
#endif
This seems to work for me, but it is certainly not the right thing to do. Make sure the file is located at the right place /Library/Developer/CommandLineTools/usr/include/c++/v1/__debug with the right owner/permissions.

This is now fixed in Command Line Tools 6.3.1, available from https://developer.apple.com/downloads. The update should appear automatically in your App Store Updates (though it’s labelled as 6.3, not 6.3.1). Apologies for the inconvenience, and thanks very much for reporting the issue.
Earlier: A workaround which worked for me in a simple case was setting a minimum of OS X 10.8 or earlier, with “-mmacosx-version-min=10.8”.

I followed #Flash Sheridan advice and got my CLT working again (git, ruby, brew...) - I used "Command Line Tools (OS X 10.10) for Xcode 6.3.1".

Related

Xcode command line tools not finding header files (Catalina Update 10.15.7)

Recently I have updated my MacBook operating system to Catalina 10.15.7 and Xcode command line tools to 12.1. Ever since I have been getting the following error when I try to use any C++ compiler:
gcc A3v2.cpp
In file included from /usr/local/include/c++/9.2.0/bits/postypes.h:40,
from /usr/local/include/c++/9.2.0/iosfwd:40,
from /usr/local/include/c++/9.2.0/ios:38,
from /usr/local/include/c++/9.2.0/ostream:38,
from /usr/local/include/c++/9.2.0/iostream:39,
from A3v2.cpp:13:
/usr/local/include/c++/9.2.0/cwchar:44:10: fatal error: wchar.h: No such file or directory
44 | #include <wchar.h>
| ^~~~~~~~~
compilation terminated.
I have tried removing and re installing command line tools but it hasn't worked (amongst trying various other solutions I've found on Stackoverflow). When I run sudo find on wchar.h I get the following.
sudo find /Library -name wchar.h
find: /Library/Application Support/com.apple.TCC: Operation not permitted
/Library/Developer/CommandLineTools/usr/include/c++/v1/wchar.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/wchar.h
As a current work around (as I need a c++ compiler for a current assignment) I have been using:
/usr/bin/gcc A3v2.cpp
however I'm hoping this will just be temporary. I think this is a path problem since the missing header file exsits? Not sure what I am doing when it comes to specifying file paths so please let me know if you know how to solve this. Thanks!

How to run c++ program in mac terminal

I have installed c++4.9 in my mac, but compilation just terminated somehow. Could someone tell me why? thanks!
If you read the line above "compilation terminated." you get an explanation of why. #include <wchar.h> was the cause of the error: wchar.h could not be found. Please read the errors the compiler shows you.
Chances are you need to reinstall the command-line tools.
It seems like the top of your terminal output (which actually prints the call to g++) is missing, but the directory that holds wchar.h is not being found. On my mac it is /usr/include/c++/4.2.1/tr1. You can add the directory to your path:
> export PATH=$PATH:/user/include/c++/4.2.1/tr1
Or use a makefile that searches this path for headers.
Of course, you need to make sure you have this header in the first place.
Go to http://developer.apple.com and command line tools installer for Mavericks otherwise you can just type this in your terminal to install all the command line tools
xcode-select --install

why am i seeing this libzdb configure error?

I am attempting to install libzdb on my macbook however I see the following error message when running the configure:
configure:13334: error: setjmp is required
the setjmp.h file resides within /usr/include and is specified within my "$PATH" as
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/include
Can someone please advise as to how i can rectify this issue?
thanks in advance
I've stumbled across this error while building one of my own programs when I wanted to use setjmp() and longjmp(). For some reason, the toolchain that resides in / on OS X is flawed, and the <setjmp.h> header file is missing the declarations and data types.
To fix it, I had to download Xcode (damn!) and tell the compiler to look for the headers in the freshly installed MacOSX10.7.sdk (or 8) folder:
clang -Wall -o foo foo.c -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
ok finally figured it out. For those who have seen messages like this be warned that the configure logs can be misleading. It turned out the binary built fine, however it was failing during runtime because a few mysql libraries could not be found. using the following command *export DYLD_LIBRARY_PATH=/usr/local/mysql/lib/* would fix the problem

LLVM libc++ not compiling with clang 3.3 on Mac OS

I have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.

Causing cpp (C preprocessor) to remove C++ comments on Mac OS X

I have a user report (unfortunately can't verify it due to lack of appropriate machine) that the C preprocessor (cpp) command on Mac OS X 10.6.4 doesn't remove C++/C99 double slash // comments from files it processes, no matter what option it's given. This is the gcc version:
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
Is it possible to somehow cause it to remove such comments, as one would expect from a C++ preprocessor (this is needed because cpp is used as part of another tool).
I've found a formula that works with the cpp command: try cpp -xc++ (note the lack of spaces between -x and c++).
$ printf '/* block comment */\n// line comment\nnot a comment\n' | cpp -xc++
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
not a comment
contrast:
$ printf '/* block comment */\n// line comment\nnot a comment\n' | cpp -x c++
i686-apple-darwin10-gcc-4.2.1: c: No such file or directory
i686-apple-darwin10-gcc-4.2.1: c++: No such file or directory
i686-apple-darwin10-gcc-4.2.1: warning: '-x -x' after last input file has no effect
i686-apple-darwin10-gcc-4.2.1: no input files
Now '-x c++' is SUPPOSED to work, and DOES work on my Linux box (with gcc 4.4, but I recall it working as long ago as gcc 2.95) so it seems that Apple broke it.
I really must reemphasize the importance of providing a complete, precise test case for questions like these. It did not occur to me yesterday to look for Apple having introduced a bug, because I know that wilx's answer should have worked, and in the absence of a precise description of what the OP's user tried, it was far more likely that they had something else on their actual command line that was negating it. If the command line and error messages I show above were provided in the original question, that would have targeted everyone's attention much more effectively.
Try adding either -x c++ or -x c -std=c99 to the command line.
One partial solution that appears to work is invoke gcc -E instead of cpp.
-E Preprocess only; do not compile, assemble or link
This indeed strips // comments on Mac OS X.
However, I'm still curious why there are problems with cpp itself.