Fix gcc6 issues - add explicit c++98 compile and link flag #116
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As per https://gcc.gnu.org/gcc-6/changes.html , the default C++ dialect in GCC 6 is updated from GNU++98 all the way to GNU++14. This causes compile errors for C++ programs that are not C++14 (or C++11) compliant, and do not request a specific dialect. As pointed out in #115 , such issues prevent BamTools from being built with GCC 6.
This pull request explicitly adds
-std=c++98
to both compile and link flags (i.e., toCXXFLAGS
), which is one way of allowing BamTools 2.4.0 to be built with GCC 6.0.0.The caveat of doing this is that the libraries produced will (if I understand correctly) use the C++98 ABI, and they might get used in a system based on the C++14 ABI. Some ABI differences are explained here: https://gcc.gnu.org/wiki/Cxx11AbiCompatibility (I couldn't find a similar document regarding C++14). A quick glance suggests
libbamtools.{a,so}
do not use any problematic symbols, but this is not a guarantee, and compatibility might be broken in the future.An alternative way of making BamTools more GCC 6 friendly would be to address dialect differences, one by one.