Clang first claimed support, via __has_feature(cxx_alignof), for C++11's alignof keyword in r223186 (December 2014). This corresponds to Clang 3.6 by the Clang project's marketing version number.
But that revision only implements the feature-test: alignof support happened earlier. Indeed, Clang's C++ status page says alignof was implemented in Clang 3.3!
I work on a project that requires Clang 3.3 (or its equivalent) but not yet Clang 3.6. Are there bugs in Clang 3.3-3.5's alignof implementation that delayed feature-testing support, or was non-support merely an oversight? Can I safely use alignof in this project, even though __has_feature(cxx_alignof) might claim alignof isn't supported?
Related
SDL2 is often described as breaking backwards compatibility with SDL 1.2.
This implies that within different versions of SDL2, the API and ABI remain backwards-compatible.
However, I have not been able to find any authoritative source confirming that this is the case.
For example, for GLIBC, Red Hat maintains a webpage which states:
One of the GNU C Library's (glibc's) unwritten rules is that a program built against an old version of glibc will continue to work against newer versions of glibc.
This guarantee is very useful for portability, as it means that a program can be compiled against an older version of GLIBC and run on any platform that ships at least that version or any newer version of GLIBC.
The closest to such a guarantee that I have been able to find for SDL2 are the release notes for PySDL2, a separate project, which make passing references to "backwards compatibility":
Improved compatibility with older SDL2 releases […]
[…] properly wrapped now to retain backwards compatibility with previous SDL2 releases
[…] provide backwards compatibility for previous SDL2 releases […]
There are also two issues on Github which make passing mentions to "backwards compatibility" in the context of using SDL2, but also aren't actually directly tied to the SDL library at all.
Is there any official or authoritative source documenting or guaranteeing backwards compatibility across different versions of SDL2?
I.E., If I compile a program to dynamically link against an older version of SDL2, is it safe to assume that it will work on platforms that provide a newer version of SDL2?
Official Statements
It appears that one of the first goals reached in the development of SDL2 was to stabilize the ABI, explicitly so that no breaking changes would happen to it until SDL 3, according to the original author and main developer of SDL:
slouken
Regular
Mar '13
As of tonight, SDL 2.0 is ABI locked!
This means that no breaking changes will happen to the API until SDL
3.
Cheers!
From the SDL wiki:
We are obsessive about SDL2 having a backwards-compatible ABI. Whether you build your game using the Steam Runtime SDK or just about any old copy of SDL2, it should work with the one that ships with Steam.
A similar process is planned for the development of SDL 3:
slouken commented 22 days ago (4 Oct 2022, 18:45 GMT)
Our current plan is to make all the ABI breaking changes immediately before the very first SDL3 release, so we have a stable ABI from the very beginning.
Empirically
If we go on abi-laboratory.pro, we may see that SDL2 has more or less kept its promise of perfect ABI compatibility throughout every release:
Source
Specific changes between each version can furthermore be reported by clicking on the percentages.
I am about to use external libraries but they does not work, when i look at them i found this
// This class file was compiled with different version of Kotlin compiler and can't be decompiled.
//
// Current compiler ABI version is 1.1.16
// File ABI version is 1.5.1
so i was wondering how to update my compiler Abi version
and also, should i be worried about, may some other external libraries conflict with this? It is posible to manage different compiler ABI version?
The Kotlin compiler should provide for specifying source and target version compatibility.
Source version means what features of the Kotlin language are supported. Should be https://kotlinlang.org/docs/compiler-reference.html#language-version-version
Target version defines what version the resulting JVM bytecode is going to be. I think this is the right switch: https://kotlinlang.org/docs/compiler-reference.html#jvm-target-version. When talking about ABI version this is what matters. Note that still you may want to change the source version if an older target version does not support new language features.
I am trying to compile NodeJS for PPC architecture but It fails with "cc1plus: error: unrecognized command line option -std=gnu++0x". From analysis I infer my Executable didn't support c++0x standard for compilation.Kindly suggest any other alternative way that i can use to compile Nodejs.
It looks like your compiler predates the C++11 standards (-std=gnu++0x is an alias for std=gnu++11). From gcc's c++ version status page:
GCC 4.8.1 was the first feature-complete implementation of the 2011 C++ standard, previously known as C++0x.
Can you use a newer compiler that supports the C++ standard required by nodejs?
I have my project currently compiling under gcc. It uses Boost, ZeroMQ as static .a libraries and some .so libraries like SDL. I want to go clang all the way but not right now. I wonder if it is possible to compile code that uses .a and .so libraries that were compiled under gcc with clang?
Yes, you usually can use clang with GCC compiled libraries (and vice versa, use gcc with CLANG compiled libraries), because in fact it is not compilation but linking which is relevant. You might be unlucky and get unpleasant suprises.
You could in principle have some dependencies on the version of libstdc++ used to link the relevant libraries (if they are coded in C++). Actually, that usually does not matter much.
In C++, name mangling might in theory be an issue (there might be some corner cases, even incompatibilities between two different versions of g++). Again, in practice it is usually not an issue.
So usually you can mix CLANG (even different but close versions of it) with GCC but you may have unpleasant surprises. What should be expected from any C++ compiler (be it CLANG or GCC) is just to be able to compile and link an entire software (and all libraries) together using the same compiler and version (and that includes the same C++ standard library implementation). This is why upgrading a compiler in a distribution is a lot of work: the distribution makers have to ensure that all the packages compile well (and they do get surprises!).
Beware that the version of libstdc++ does matter. Both Clang & GCC communities work hard to make its ABI compatible for compiler upgrades, but there are subtle corner cases. Read the documentation of your particular and specific C++ standard library implementation. These corner cases could explain mysterious crashes when using a good C++ library binary (compiled with GCC 5) in your code compiled with GCC 8. The bug is not in the library, but the ABI evolved incompatibly.
At least for Crypto++ library this does not work (verified :-( ). So for c++ code it is less likely to work, while pure c code would probably link OK.
EDIT: The problem started appearing with Mac OS X 10.9 Mavericks and Xcode-5, which switched the default C++ library for clang from libstdc++ to libc++. It did not exist on Mac OS X 10.8 and earlier.
The solution appears to be: if you need to compile C++ code with clang, and link it to a gcc-compiled library, use "clang++ -stdlib=libstdc++". The linking is successful, and the resulting binary runs correctly.
CAVEAT: It does not seem to work the other way: even though you can build a library compiled with "clang++ -stdlib=libstdc++" and link gcc-compiled code with it, this code will crash with SEGV. So far I found the only way to link with a clang-compiled library is compiling your code with clang, not gcc.
EDIT2:
GCC-12 seems to include -stdlib= flag. Compiling with g++ -stdlib=libc++ creates Clang++-compatible object files. Very nice.
I do have an additional data point to contribute, on the topic of "unpleasant surprises" mixing code from different versions of different compilers. Therein, I link Victor Shoup's C++-based NTL number theory library with a small piece of driver code that just prints out a large factorial computed by the NTL code, a number with a decimal representation that might span multiple lines if sufficiently large.
I have built and installed SageMath (and its version of NTL) on my system running OS X 10.11.6, and also have a current installation of MacPorts. In /usr/bin I find for gcc --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
My MacPorts gcc gives
gcc (MacPorts gcc9 9.1.0_2) 9.1.0
Now, the SageMath build system requires that MacPorts be moved out of the way, so I assume SageMath builds NTL using Apple's development toolset. The SageMath build log is full of invocations of gcc. SageMath actually builds gcc from source if the system on which the makefile is run has too old a version of Apple's developer tools.
My driver code computes big factorials and uses methods of the NTL class ZZ; I initially had tested this by linking to an NTL static library I built myself, and I changed it to link to the SageMath version because I find it pleasing not to duplicate libraries. Now I understand a bit more about the pitfalls which may arise in this process.
The old makefile invoked g++ to make the executable, but this failed at linking phase with the message:
Undefined symbols for architecture x86_64:
"NTL::operator<<(std::basic_ostream<char, std::char_traits<char> >&, NTL::ZZ const&)",
referenced from:
prn_factorial(int, NTL::ZZ&) in print.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
I had to think about this and run experiments for about 15 minutes before deciding on my own to change the makefile to invoke clang++ which in my current path invokes the MacPorts version
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-7.0/bin
This time, the makefile successfully linked and built my executable. I conclude that this represents one of those edge cases with "unpleasant surprises". Probably I should conclude that working with details of C++ is not for me; big software systems like SageMath are developed just so hobbyists don't really have to muck around with details like these.
Is it possible to do cross-compilation with the Glasgow Haskell Compiler for common architectures?
If not, is this feature planned to be developed in the near future?
As of this moment (GHC 7.0) GHC does not support cross-compilation.
As of 2013, "support for cross-compilation works reasonably well in GHC 7.8.1".
See the status on the CrossCompilation wiki page.
Discussion
GHC has always supported self-cross-compilation (i.e. you can port GHC to a new architecture). However, GHC as a cross-compiler, that runs on a host, but produces binaries that target another, has not been supported.
As of GHC 7 though, with the new LLVM backend, work is being undertaken to add cross-compilation support.
Status appears to be, from Mark Lentczner, "At this point I can build and link and run a stage1 cross-compiler." So stay tuned for GHC 7.2