The macro __GLIBCXX__ contains the time stamp of libstdc++ releases, e.g., from gcc documentation (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html)
__GLIBCXX__
The current version of libstdc++ in compressed ISO date format, as an unsigned long. For details on the value of this particular macro for a particular release, please consult the ABI Policy and Guidelines appendix.
I am looking for the values for all releases since the release of 4.9.0 (including releases of smaller versions like 4.8.x).
The documentation of libstdc++ does not seem to provide this information (it only provides the dates up to gcc 4.7.0).
Where can I find the values of __GLIBCXX__? Does anybody have them?
The ABI Policy and Guidelines appendix (https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html) says
Incremental bumping of a library pre-defined macro. For releases before 3.4.0, the macro is GLIBCPP. For later releases, it's GLIBCXX. (The libstdc++ project generously changed from CPP to CXX throughout its source to allow the "C" pre-processor the CPP macro namespace.) These macros are defined as the date the library was released, in compressed ISO date format, as an unsigned long.
but then only provides the values of the macro up to GCC 4.7.0. Still the day of a particular GCC releases are listed here:
https://gcc.gnu.org/releases.html
but for example for GCC 4.9.1 with release date "July 16, 2014" the ISO date format is 20140716 and the value of __GLIBCXX__ is 20140617 (notice the 7 and 6 have been switched).
The information you want is useless anyway, so you should solve your problem a different way.
GCC 4.9.3 was released after GCC 5.3, so it has a later date in that macro, so you can't just do something like:
#if __GLIBCXX__ > 20150422 // GCC 5.1 release
because that would be true for 4.9.3, but that doesn't have all the features that 5.1 has.
Most GNU/Linux distros don't ship official FSF releases either, they build snapshots, which will have the date of the snapshot, which won't be in any list of release dates. And a snapshot from the 5.x branch on a given day will have the same date as a snapshot from the 6.x branch on a given day, so you can't tell them apart.
In the interest of answering the original question, here's a hacky command you can execute in your shell to get the list of releases and the value of __GLIBCXX__ for each release (starting with v4.1.0):
svn list "svn://gcc.gnu.org/svn/gcc/tags" | grep -o "gcc_\([^34]_.*\|4_[^0]_.*\)_release" | xargs -n 1 -I {} sh -c "printf \"{}: \" && svn cat svn://gcc.gnu.org/svn/gcc/tags/{}/gcc/DATESTAMP"
The results are:
4.1.0: 20060228
4.1.1: 20060524
4.1.2: 20070214
4.2.0: 20070514
4.2.1: 20070719
4.2.2: 20071007
4.2.3: 20080201
4.2.4: 20080519
4.3.0: 20080305
4.3.1: 20080606
4.3.2: 20080827
4.3.3: 20090124
4.3.4: 20090804
4.3.5: 20100522
4.3.6: 20110627
4.4.0: 20090421
4.4.1: 20090722
4.4.2: 20091015
4.4.3: 20100121
4.4.4: 20100429
4.4.5: 20101001
4.4.6: 20110416
4.4.7: 20120313
4.5.0: 20100414
4.5.1: 20100731
4.5.2: 20101216
4.5.3: 20110428
4.5.4: 20120702
4.6.0: 20110325
4.6.1: 20110627
4.6.2: 20111026
4.6.3: 20120301
4.6.4: 20130412
4.7.0: 20120322
4.7.1: 20120614
4.7.2: 20120920
4.7.3: 20130411
4.7.4: 20140612
4.8.0: 20130322
4.8.1: 20130531
4.8.2: 20131016
4.8.3: 20140522
4.8.4: 20141219
4.8.5: 20150623
4.9.0: 20140422
4.9.1: 20140716
4.9.2: 20141030
4.9.3: 20150626
5.1.0: 20150422
5.2.0: 20150716
5.3.0: 20151204
6.1.0: 20160427
6.2.0: 20160822
6.3.0: 20161221
6.4.0: 20170704
7.1.0: 20170502
7.2.0: 20170814
7.3.0: 20180125
Note that these values are from the official releases from the GCC team. If you're using an unofficial release, the values might differ slightly.
You can generate a list of possible __GLIBCXX__ values using the SVN release listing as source:
svn list --xml 'https://gcc.gnu.org/svn/gcc/tags' \
| grep '>gcc.*release' -A4 \
| grep 'name\|date' \
| sed -e 's/<[^>]\+>//g' -e 's/T.*$//' -e 's/-//g' \
-e 's/gcc_\|_release//g' \
| paste - -
A similar list, but more free-form and annotate with branching ascii art is maintained by the GCC team:
https://gcc.gnu.org/develop.html#timeline
Note that multiple release branches are active in parallel, cf e.g. the 4.8 and 4.9 branches:
4_8_0 20130322
4_8_1 20130531
4_8_2 20131016
4_8_3 20140522
4_8_4 20141219
4_8_5 20150623
4_9_0 20140422
4_9_1 20140716
4_9_2 20141030
4_9_3 20150626
4_9_4 20160803
Thus, unfortunately, you can't use a single date as simple cut-off value to determine a certain release.
Of course, you can auto-generate some helper macros from this list. Say - you need some workaround for the 4.8 GLIBCXX release (as used by GCC and different clang versions) then you could define a helper macro like this (after including some STL header):
#if __GLIBCXX__ == 20130322 \
|| __GLIBCXX__ == 20130531 \
|| __GLIBCXX__ == 20131016 \
|| __GLIBCXX__ == 20140522 \
|| __GLIBCXX__ == 20141219 \
|| __GLIBCXX__ == 20150623
#define HAVE_GLIBCXX_4_8 1
#else
#define HAVE_GLIBCXX_4_8 0
#endif
If you are just interested in the major version and only need to support releases newer than GCC 7 than you can also use the _GLIBCXX_RELEASE macro.
Related
Under Ubuntu 64 bit I got
llc --version
LLVM (http://llvm.org/):
LLVM version 3.1
Optimized build with assertions.
Built Oct 15 2012 (18:15:59).
Default target: x86_64-pc-linux-gnu
Host CPU: btver1
Registered Targets:
arm - ARM
mips - Mips
mips64 - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel - Mipsel
thumb - Thumb
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
I can't do this
clang -march=arm -x c++ /tmp/cpp.cpp
error: unknown target CPU 'arm'
I'm missing something here ? Why I can't compile for ARM ?
-march is LLVM's internal tools command line option and is not connected with clang at all. If you need to compile for other target you need to specify the target triplet. This can be done in several ways (I do not remember offhand, whether they work with 3.1, but they definitely work with 3.2):
Make a link from clang to your-target-triple-clang, e.g. to
arm-none-linux-gnueabi-clang and compile everything via it
Provide -target option, e.g. clang -target arm-none-linux-gnueabi
To get a list of options of the clang compiler, use:
clang -cc1 -help
To specify the target, use -triple:
clang -cc1 -triple "arm-vendor-os" filename
where "vendor" and "os" should be replaced with the actual vendor and OS name. It can also be replaced with unknown.
-triple is a string of the form ARCHITECTURE-VENDOR-OS or ARCHITECTURE-VENDOR-OS-ENVIRONMENT. For example: x86_64-apple-darwin10
the llvm linker links for the host, which is only one of the targets, it wont link to every target in the list. it will definitely compile for any target. Basically clang goes from C/C++ to bytecode, then llc takes bytecode and makes assembly for the specific target (new experrimental option to take the bytecode straight to object file) then you need to get a cross assembler and a cross linker to take it the final mile (I use gnu binutils). Unfortunately I found that clang to bytecode is not completely generic (I had hoped and expected that it would be), it does in fact change the target independent output based on the target. The example below using the host triple instead of using -march allowed for my examples to build properly on more hosts.
ARMGNU?=arm-none-eabi
LOPS = -Wall -m32 -emit-llvm -ccc-host-triple $(ARMGNU)
OOPS = -std-compile-opts
LLCOPS = -march=thumb -mtriple=$(ARMGNU)
clang $(LOPS) -c blinker03.c -o blinker03.clang.bc
opt $(OOPS) blinker03.clang.bc -o blinker03.clang.thumb.opt.bc
llc $(LLCOPS) blinker03.clang.thumb.opt.bc -o blinker03.clang.thumb.opt.s
$(ARMGNU)-as blinker03.clang.thumb.opt.s -o blinker03.clang.thumb.opt.o
$(ARMGNU)-ld -o blinker03.clang.thumb.opt.elf -T memmap vectors.o blinker03.clang.thumb.opt.o
I have not, but before long will experiment with using the llc straight to object (actually I tried it on a simple test but have not used it on anything larger or posted it anywhere).
You're confusing your flags. clang's -march= wants a processor family. You probably meant to use clang -arch arm instead.
As this comment says this option it's not supported yet under linux, for now.
"-arch arm" is equivalent to "-arch armv4t" in clang. I suppose that a generic "arm" target is not allowed with "-march=", which should require something more precise, such as "armv6", "thumbv7", "armv4t", ...
Try selecting a specific subarch.
Starting Clang 11 (trunk), the list of supported target architectures could be handily printed using the newly added -print-targets flag.
I am trying to detect Solaris/SunOS version at compile time so that I can enable/disable use of port_create() and other APIs.
Is there a header identifying SunOS/Solaris version at compile time?
If no header is giving you this information, you could of course parse the output of uname and generate -D preprocessor option(s) from your build script/makefile/...
Elaborating upon the suggestion by #meaning-matters, one can make a compile-time definition, say SUN_VERSION using the output of uname -r. That actually gives a floating point number, e.g., 5.10, which you could convert into a preprocessor-comparable form using a simple sed command, e.g., this compiler option:
-DSUN_VERSION=`uname -r | sed -e 's/\.\([0-9]\{1,1\}\)$/0\1/' -e 's/\.//'`
produces 510 for 5.10, 509 for 5.9, etc.
In your source program, you could use it like this
#if SUN_VERSION >= 510
(or whatever makes sense).
Identifying the OS release in order to assert an API is available or not is risky if not doomed. You cannot assume an API will stay in future releases nor if it is available in a parallel branch (eg. Illumos vs Solaris 11 which are both reporting SunOS 5.11 as their version).
The usual way to overcome this issue is simply to check if the API is available by compiling a small test source code to figure it out. This is usually done in a script traditionally named configure that builds a Makefile and an include file tailored to your system.
To expand upon #meaning-matters answer, use GNU make, and set a variable to the OS version. Pass that variable on to the compiler using the -D command-line option.
Makefile:
OS_VERSION := $(shell uname -r)
version:
$(CC) -DOS_VERSION=$(OS_VERSION) version.c -o version
test:
echo $(OS_VERSION)
version.c:
#include <stdio.h>
#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)
int main()
{
printf( "OS Version: " TOSTRING(OS_VERSION) "\n" );
return( 0 );
}
Output:
bash 4.1$ gmake test
echo 5.11
5.11
bash 4.1$ gmake version
cc -DOS_VERSION=5.11 version.c -o version
bash 4.1$ ./version
OS Version: 5.11
bash 4.1$
Use := (assign if not already set) to only run the uname command once.
That will show "5.10" for Solaris 10, "5.11" for Solaris 11.
I can't compile the openssl headers for c++ on Angstrom distribution, arm core. The file "bn.h" in openssl needs some extra definitions. One of them is THIRTY_TWO_BIT. I don't want to define it manually cause I may dismiss some other defines.
What header files should I include to have the THIRTY_TWO_BIT defined and openssl headers compiled as a result?
Googling for #define THIRTY_TWO_BIT yields the result that opensslconf.h seems to define THIRTY_TWO_BIT, see Apples codebase here
where is THIRTY_TWO_BIT defined?
Its defined by Configure based on the platform:
$ cd <openssl src dir>
$ grep -R THIRTY_TWO_BIT *
...
Configure:"BS2000-OSD","c89:-O -XLLML -XLLMK -XL -DB_ENDIAN -DTERMIOS -DCHARSET_EBCDIC::(unknown)::-lsocket -lnsl:THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::",
Configure:"OS390-Unix","c89.sh:-O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE::(unknown):::THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR:::",
Configure:"tandem-c89","c89:-Ww -D__TANDEM -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -D_TANDEM_SOURCE -DB_ENDIAN::(unknown):::THIRTY_TWO_BIT:::",
...
Its used in other files, and available in opensslconf.h if it was defined during configure (as Uli pointed out):
...
crypto/opensslconf.h.in:#define THIRTY_TWO_BIT
crypto/bn/bn_lib.c:#if defined(THIRTY_TWO_BIT) || defined(SIXTY_FOUR_BIT) || defined(SIXTY_FOUR_BIT_LONG)
crypto/bn/bn_lib.c:#if defined(THIRTY_TWO_BIT) || defined(SIXTY_FOUR_BIT) || defined(SIXTY_FOUR_BIT_LONG)
crypto/bn/bn_gf2m.c:#ifdef THIRTY_TWO_BIT
crypto/bn/bn_gf2m.c:#ifdef THIRTY_TWO_BIT
crypto/bn/bn.h:#ifdef THIRTY_TWO_BIT
MacOS/opensslconf.h:#define THIRTY_TWO_BIT
I can't compile the openssl headers for c++ on Angstrom distribution, arm core. The file "bn.h" in openssl needs some extra definitions.
You might check in Configure for a similar platform, and then copy/add/modify it for your platform. Then, run ./Configure <your new platform> followed by a make all.
Your platform may already be available. There is no Angstrom, but there are ARM's available:
$ ./Configure
Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...]
[-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared]
[[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR]
[--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]
pick os/compiler from:
BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8
BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-pre1.3 DJGPP MPE/iX-gcc OS2-EMX
OS390-Unix QNX6 QNX6-i386 ReliantUNIX SINIX SINIX-N UWIN VC-CE VC-WIN32
VC-WIN64A VC-WIN64I aix-cc aix-gcc aix3-cc aix64-cc aix64-gcc android
android-armv7 android-x86 aux3-gcc beos-x86-bone beos-x86-r5 bsdi-elf-gcc cc
cray-j90 cray-t3e darwin-i386-cc darwin-ppc-cc darwin64-ppc-cc
darwin64-x86_64-cc dgux-R3-gcc dgux-R4-gcc dgux-R4-x86-gcc dist gcc hpux-cc
hpux-gcc hpux-ia64-cc hpux-ia64-gcc hpux-parisc-cc hpux-parisc-cc-o4
hpux-parisc-gcc hpux-parisc1_1-cc hpux-parisc1_1-gcc hpux-parisc2-cc
hpux-parisc2-gcc hpux64-ia64-cc hpux64-ia64-gcc hpux64-parisc2-cc
hpux64-parisc2-gcc hurd-x86 iphoneos-cross irix-cc irix-gcc irix-mips3-cc
irix-mips3-gcc irix64-mips4-cc irix64-mips4-gcc linux-alpha+bwx-ccc
linux-alpha+bwx-gcc linux-alpha-ccc linux-alpha-gcc linux-aout linux-armv4
linux-elf linux-generic32 linux-generic64 linux-ia32-icc linux-ia64
linux-ia64-ecc linux-ia64-icc linux-ppc linux-ppc64 linux-sparcv8
linux-sparcv9 linux-x86_64 linux32-s390x linux64-s390x linux64-sparcv9 mingw
mingw64 ncr-scde netware-clib netware-clib-bsdsock netware-clib-bsdsock-gcc
netware-clib-gcc netware-libc netware-libc-bsdsock netware-libc-bsdsock-gcc
netware-libc-gcc newsos4-gcc nextstep nextstep3.3 osf1-alpha-cc osf1-alpha-gcc
purify qnx4 rhapsody-ppc-cc sco5-cc sco5-gcc solaris-sparcv7-cc
solaris-sparcv7-gcc solaris-sparcv8-cc solaris-sparcv8-gcc solaris-sparcv9-cc
solaris-sparcv9-gcc solaris-x86-cc solaris-x86-gcc solaris64-sparcv9-cc
solaris64-sparcv9-gcc solaris64-x86_64-cc solaris64-x86_64-gcc sunos-gcc
tandem-c89 tru64-alpha-cc uClinux-dist uClinux-dist64 ultrix-cc ultrix-gcc
unixware-2.0 unixware-2.1 unixware-7 unixware-7-gcc vos-gcc vxworks-mips
vxworks-ppc405 vxworks-ppc60x vxworks-ppc750 vxworks-ppc750-debug
vxworks-ppc860 vxworks-ppcgen vxworks-simlinux ...
When using gcc version 4.3.2, I see how to generate specs using:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
Now changing to the same directory as libgcc:
cd /usr/local/gcc-4.3.2/lib/gcc/x86_64-unknown-linux-gnu/4.3.2
/usr/local/gcc-4.3.2/bin/gcc -dumpspecs > specs
I have a populated specs file that I can modify. However, once that is done I still see that:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
How do I tell gcc to use that specs file by default rather than forcing me to pass a -specs parameter every compile? I would like it to match another system I have where I get the following:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Reading specs from /usr/local/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/specs</code>
As you can see, the major difference between the two systems is that the existing setup is 32-bit and I am now trying to match that on a 64-bit system. The version of Linux is otherwise the same and I am compiling the same version of gcc. (With both systems gcc 4.3.2 is the second gcc installation, with 4.1.2 being used to compile 4.3.2)
As hinted at by the strace suggestion by Johannes Schaub - litb, it was a problem with where the compiler was looking for the file. As it turns out, the non-working installation had an environment variable set in the .bashrc that was causing the confusion.
The correct location for the specs file is indeed the same directory that libgcc is in. Just be sure you're looking there.
I used this command line:
/usr/bin/set-gcc-default-3.sh i686-pc-mingw32
but you'll probably want:
/usr/bin/set-gcc-default-4.sh i686-pc-linux-gnu
(Note the -4 instead of -3)
This is built using the "alternatives" stuff, please see
/usr/sbin/alternatives.exe --help
And also see pages such as http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
You rebuild gcc with your specs file as part of the build!
A simpler solution is to create an alias:
alias gcc_Gary gcc -specs /<folder With Specs File>/newSpecsFile
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.