Recent MinGW version (v5.0.2) introduced some DirectX updates which declare some XInput structs that are already defined in SDL(2.0.4). Preventing it from compiling. I would like to add some macros around SDL's XINPUT_GAMEPAD_EX and XINPUT_STATE_EX structs to prevent them from being declared on that particular MinGW-w64 version.
I can't test for GCC 6.3.0 because it worked on the previous revision. Just this last one that causes the issue.
And I just can't find any information related to detecting the patch/revision number. Some compile time macro or something. There's only information on finding the the major/minor version numbers. I need to detect that .2.
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.
To repeat: I'm looking for ABI compatibility between libraries of the same Visual-C++ version!
We want to mix and match some internal C++ DLLs from different teams - built at different times with different project files. Because of long build times, we exactly want to avoid large monolithic builds where each team re-compiles the source code of another team's library.
When consuming C++ DLLs with C++ interfaces it is rather clear that you only can do this if all DLLs are compiled with the same compiler / Visual Studio version.
What is not readily apparent to me is what, exactly needs to be the same to get ABI compatibility.
Obviously debug (_DEBUG) and release (NDEBUG) cannot be mixed -- but that's also apparent from the fact that these link to different versions of the shared runtime.
Do you need the exact same compiler version, or is it sufficient that the resulting DLL links to the same shared C++ runtime -- that is, basically to the same redistributable? (I think static doesn't fly when passing full C++ objects around)
Is there a documented list of compiler (and linker) options that need to be the same for two C++ DLLs of the same vc++ version to be compatible?
For example, is the same /O switch necessary - does the optimization level affect ABI compatibility´? (I'm pretty sure not.)
Or do both version have to use the same /EH switch?
Or /volatile:ms|iso ... ?
Essentially, I'd like to come up with a set of (meta-)data to associate with a Visual-C++ DLL that describes it's ABI compatibility.
If differences exist, my focus is on VS2015 only at the moment.
Have been thinking this through the last days, and what I did do was to try to see if some use-cases exists where devs have already needed to categorize their C++ build to make sure binaries are compatible.
One such place is the Native Packages from nuget. So I looked at one package there, specifically the cpprestsdk:
The binaries in the downloadable package as split like this:
native\v120\windesktop\msvcstl\dyn\rt-dyn\x64\Release\
^ ^ ^ ^ ^
VS version | not sure | uses cpp-runtime dynamically
| lib itself dynamic (as opposed to static)
or WinXP or WinApp(WinRT?)
I pulled this out from this example, because I couldn't find any other docs. I also know that the boost binaries build directory is separated in a similar way.
So, to get to a list of meta data to identify the ABI compatibility, I can preliminarily list the following:
VC version (that is, the version of the C and CPP runtime libraries used)
one point here is that e.g. vc140 should be enough nowadays - given how the CRT is linked in, all possible bugfixes to the versioned CRT components must be ABI compatible anyway, so it shouldn't matter which version a given precompiled library was built with.
pure native | managed (/CLI) | WinRT
how the CRT is consumed (statically / dynamically)
bitness / platform (Win32, x64, ARM, etc.)
Release or Debug version (i.e. which version of the CRT we link to)
plus: _ITERATOR_DEBUG_LEVEL ... if everyone goes with the defaults, fine, if a project does not, it must declare so
Additionally my best guess as to the following items:
/O must not matter - we constantly mix&match binaries with different optimization settings - specifically, this is even working for object files within the same binary
/volatile - since this is a code-gen thing, I have a hard time imagining how this could break an ABI
/EH - except for the option to disable all exception, in which case you obviously can't call anything that throws, I'm pretty confident this is save from an ABI perspective: There are possible pitfalls here, but I think they can't really be categorized into ABI compat. (Maybe some complex callback chains could be said to be ABI incompatible, not sure)
Others:
Default calling convention (/G..) : I think this would break at link time, when mangled export symbols and header declarations don't match up.
/Zc:wchar_t - will break at link time (It's actually ABI compatible, but the symbols won't macth.)
Enable RTTI (/GR) - not too sure 'bout this one - I never have worked with this disabled.
I follow a version scheme for a library with a version number of three parts and a so version of two parts. example-1.0.0 and libexample.so.1.0.
The last number in the version string is updated when I make changes without breaking the ABI. The second number is updated when I add new symbols and the major version number is used for incompatible changes.
The so version is updated when symbols are added even if it does not break compatibility with other programs. This means that programs need to be recompiled because the so version has changed even if the library still is ABI compatible with older versions.
Should I avoid updating the so version when I add new symbols?
This means that programs need to be recompiled because the so version has changed even if the library still is ABI compatible with older versions.
That means you are not doing it correctly. You should only change SONAME when doing ABI-incompatible change. It is customary to use example.1 as the SONAME. Documentation.
P.S. If you only care about Linux, you likely should stop doing external versioning altogether, and instead use symbol versioning to provide a single libexample.so.1 that provides multiple ABI-incompatible symbols to both old and new client binaries.
I am trying to compile a piece of software written in Fortran 77. I should point out that I don't know much at all about Fortran, and would really rather not start modifying the code for this software - particularly as I'm not sure what the licensing of the software is, and I don't know if I would be able to redistribute my modified version.
The code compiles fine on OS X and Windows using the g77 compiler that is (fairly easily) available for these systems. However, I cannot get it to work on my Ubuntu distribution, as I can't seem to get hold of g77 for Ubuntu anymore, and if I try and install an old version of it, it seems to muck up my entire GCC installation. I have tried compiling the code with both gfortran and g95, but it doesn't work with either as:
The code uses real variables as loop indices (yes, I know, bad idea). g95 supports this with the -freal-loops option, but gfortran doesn't.
The code uses real variables to index into arrays, which gfortran will support (with a warning), but g95 won't support.
Can anyone suggest a way to compile this code with those two 'dodgy' features using a modern and easily-available compiler such as g95 or gfortran?
Pass the argument -std=legacy to gfortran. Features removed in F95, like real loop and array indices, should compile (perhaps with a warning) in legacy mode.
I am currently working on updating the build system for a large pile of code, which happens to include a Linux C++ project. It would be nice if all of the developers here could run a build when hacking around with their own ideas, so I was examining if it would be possible to build this on vaguely modern Linux systems despite the target system being 2.6.18.
By 'vaguely modern' I am estimating something like GCC 4.5+, something that a distribution in the past year or two might come with. Currently I solve the libstdc++ issue by compiling that in statically, and any glibc issues are neatly worked around by remapping to old versions of the memcpy symbols (and so on) with a quick bit of wrapper code. So far so good.
The one problem I can't seem to completely figure out is that certain symbols built into the executable from the .o files are of type 'u', which is a GNU unique object, an extension to the ELF standard that 2.6.18 doesn't seem to recognise at all. This means the executable won't run because it can't find the symbols, though they are in fact present (just of type '?' on the target, from 'nm').
One can disable the use of GNU unique objects when compiling G++ but it's not exactly the most convenient solution. I can't see any way to just disable it when compiling code (distro gcc/g++ invariably has this option on), and I imagine the only way to get the target system to recognise it would be to update ld-linux and the kernel. That's almost certainly not going to happen.
Is there an option I haven't found to disable these symbol types? Or perhaps is there some neat way around this, or something that I'm missing? I am beginning to suspect it will just have to be compiled on G++ 4.1.x, which will mean an old Linux installation or building that from source.
I was trying to deal with the same problem (which led me to finding this question) and after a bunch of research came to the definitive conclusion that no, you are not missing anything, there is no way around this besides compiling your own g++. See this recent question on the gcc-help mailing list:
http://gcc.gnu.org/ml/gcc-help/2013-01/msg00008.html
I compared gcc sources and found that you can go as high as stock 4.4, as unique symbols were added in 4.5. However on RHEL/CentOS 6 they default to 4.4 but patched unique symbol support into it, so as usual one must beware of distribution-specific gcc versions. For me this is a huge bummer as it means that things compiled on RHEL 6 can't be run on RHEL 5, even with a copy of libstdc++ made just for gcc 4.4 + RHEL 5.
Here's the message where unique symbol support was first proposed, by the way:
https://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html
If you search around you'll find that people have complained about it on other lists for various reasons, but I guess it's here to stay.