A tool for checking backward API/ABI compatibility of a C/C++ library
Home Page: https://lvc.github.io/abi-compliance-checker/
License: GNU Lesser General Public License v2.1
We can define multiple macros with gcc -Dmacro1 -Dmacor2, but it seems that -gcc-options -Dmacro1 -Dmacro2 would lead to a failure, could you give some comments on how to use -gcc-options to define mutiple macros ?
I forward a bug I submitted to the Debian bug tracker:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805441
See the above link for details.
@lvc
Hi,
With MingGW on Windows I got following errors when compile one project, do you have any suggestions?
In file included from .../mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0,
from .../mingw64/x86_64-w64-mingw32/include/stdio.h:9,
from ...64_vc14_sdk/include/atf_api/sdk/atf_core.h:17,
from ...64_vc14_sdk/include/atf_api/sdk/atf_system.h:13,
from ...64_vc14_sdk/include/atf_api/sdk/atf_assert_option.h:19,
from ...64_vc14_sdk/include/atf_api/sdk/atf.h:23,
from C:\Users\zhuda\AppData\Local\Temp\6SjF31KHIV/dump2.h:10:
E:/git.autodesk.com/binary-compatible-checker/abi-compliance-checker-dependency/mingw64/x86_64-w64-mingw32/include/_mingw.h:542:2: error: missing terminating " character
asm volatile("int {$}3":);
^
In file included from ../mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0,
from ../mingw64/x86_64-w64-mingw32/include/stdio.h:9,
from ..64_vc14_sdk/include/atf_api/sdk/atf_core.h:17,
from ..64_vc14_sdk/include/atf_api/sdk/atf_system.h:13,
from ..64_vc14_sdk/include/atf_api/sdk/atf_assert_option.h:19,
from ..64_vc14_sdk/include/atf_api/sdk/atf.h:23,
from C:\Users\zhuda\AppData\Local\Temp\6SjF31KHIV/dump2.h:10:
E:/mingw64/x86_64-w64-mingw32/include/_mingw.h: In function 'void __debugbreak()':
E:/mingw64/x86_64-w64-mingw32/include/_mingw.h:542:3: error: '$' was not declared in this scope
asm volatile("int {$}3":);
^
E:/mingw64/x86_64-w64-mingw32/include/_mingw.h:543:1: error: expected ';' before '}' token
}
Suppose I expose an interface like this:
class Foo
{
public:
virtual void take(std::vector<Thingy> const& things) = 0;
};
where in ver 1 of the library Thingy is:
struct Thingy
{
int x;
};
and in ver 2 Thingy is:
struct Thingy
{
int x;
int y;
};
An ABI break should be reported in such case.
Attached is a small test case that exhibits the issue.
Hi @lvc ,
I am wondering if there is ways to specify the compile using 'cl.exe' on Windows instead of using GCC?
https://github.com/lvc/abi-compliance-checker/blob/master/abi-compliance-checker.pl#L31
I found it's hard to use GCC on Windows to make the compile pass.
Hi,
When a pure virtual function is added to a class, the change is shown on "Problems with Data Types" section with message like below.
"Pure virtual method A::B ( int, enum ) has been added to this class. Recompilation of a client program may be broken with the error message: cannot allocate an object of abstract type A because the following virtual functions are pure within A: virtual A::B ( int, enum ). "
But in case of a function(not virtual), the change is not only shown on "Problems with Data Types" but also "Added Symbols" section.
Is it an expected result? or an issue?
Thanks.
I was testing abi-compliance-checker (1.99.17) and tried with two versions of openssl, and this is what I got:
changed to:
CRYPTO_memcmp ( void const volatile* a, void const volatile* b, size_t len )
| Change | Effect | |
|---|---|---|
| 1 | Type of 1st parameter a has been changed from void const* to void const volatile* (removed const qualifier). | This function may change parameter a, but it will be treated as const by old client applications. This may result in crash or incorrect behavior of applications. |
| 2 | Type of 2nd parameter b has been changed from void const* to void const volatile* (removed const qualifier). | This function may change parameter b, but it will be treated as const by old client applications. This may result in crash or incorrect behavior of applications. |
It would be handy to have a way to skip low-severity warning for properly added fields to the end of a structure (if size is not changed). It's compatible change for some libraries.
May be we can add a new option to vary severity of this particular ABI change w/o the need to manually edit the RulesBin.xml file.
While evaluating abi-compliance-checker on a C++ library I get varying results when I run it multiple times on exactly the same input. This basically makes it unusable.
In my case, one function is sometimes reported as having a parameter order change, sometimes not. The function looks like
boost::shared_ptr<A> find(const std::set<boost::shared_ptr<A>, Comp>&, const std::string& key);When abi-compliance-checker produces an incompatibility warning, it says that the parameter order has changed to
boost::shared_ptr<A> find(const std::set<boost::shared_ptr<A>, Comp>&, const std::string& key);(i.e. it is not changed at all) but the mangled symbol is actually changed so that c++filt prints
boost::shared_ptr<A> find(const std::set<Comp, boost::shared_ptr<A> >&, const std::string& key);What changed here is the order of the template parameters for the std::set, not the function parameter order. The mangled symbol with the swapped template parameters only exists in the compat_report.html file (when an error is reported), not in any debug output.
I am using the ubuntu trusty packaged version of abi-compliance-checker.
Under Windows, "DIR" is an internal command, so it cannot be found with get_CmdPath("dir")
Here is a patch that fixes this problem: https://gist.github.com/raphaelh/386467ff775dbf8e1b6e
Hello,
I'm using the ABI-Compliance-Checker under Windows, to check some static libs compiled with Visual Studio 2008. The tool works fine, except it finds lots of removed Symbols in the Source report, which are in fact there. This includes Symbols from std-headers, or boost, which clearly have not changed, see the screenshot for an example.
I traced the issue and found out that the selectSymbol method returns false, because the header is not in $In::Desc{$V}{"TargetHeader"}.
So I checked where it is set in the Module SysFiles, Method addTargetHeaders there is the line 2317:
if( familiarDirs($RegDir, $Dir) or $RecursiveIncludes{$LVer}{$RegHeader}{$RecInc}!=1) { # in the same directory or included by #include "..." $In::Desc{$LVer}{"TargetHeader"}{getFilename($RecInc)} = 1; }
This returns false for headers containing the symbols which cause the errors. So I wondered if the "!=1" part in $RecursiveIncludes{$LVer}{$RegHeader}{$RecInc}!=1 might be a mistake, since when I remove it, the program seems to run fine and the false removed symbol errors disappear.
Except in one case which I'm currently investigating.
If you need more info, I can provide you with more details.
Thank you for the awesome tool!
Edit: Okay, it only fixed most of the errors not all, I still have some issues with standard headers:
I'm looking into this now.
Edit2: I checked the extended mode, then the issues also appear in the binary report. The issues now only concern standard headers like strings.h, cwchar, direct.h, io.h, process.h, stat.h, string.h, and a few others, but only std-headers.
Any possibility for Fortran support?
abi-compliance-checker -dump-system name -sysroot /
Undefined subroutine &main::clean_path called at
/usr/bin/../share/abi-compliance-checker/modules/Internals/SysCheck.pm
line 1065.
readSystemDescriptor in SysCheck.pm doesn't take -relpath option into account
Hi. In many places abi-compliance-checker calls external commands and throws out stderr messages:
abi-compliance-checker.pl:1748: if(`find \"$TMP_DIR\" -maxdepth 0 2>\"$TMP_DIR/null\"`) {
abi-compliance-checker.pl:1760: if(`$Name /? 2>\"$TMP_DIR/null\"`) {
abi-compliance-checker.pl:8116: my $Info = `$CTags --version 2>\"$TMP_DIR/null\"`;
abi-compliance-checker.pl:8125: system("$CTags --c-kinds=pxn -f \"$Out\" \"$Path\" 2>\"$TMP_DIR/null\"");
abi-compliance-checker.pl:8183: $Content = `$PreprocessCmd 2>\"$TMP_DIR/null\"`;
abi-compliance-checker.pl:8209: $Content = `$PreprocessCmd 2>\"$TMP_DIR/null\"`;
abi-compliance-checker.pl:8705: system($Cmd." >\"$Out\" 2>\"$TMP_DIR/null\"");
abi-compliance-checker.pl:8729: my @Files = split(/\n/, `$Cmd 2>\"$TMP_DIR/null\"`);
abi-compliance-checker.pl:8780: my $Res = `$Cmd 2>\"$TMP_DIR/null\"`;
abi-compliance-checker.pl:18829: open(APP, "$NM -g \"$Path\" 2>\"$TMP_DIR/null\" |");
abi-compliance-checker.pl:18844: open(APP, "$DumpBinCmd /IMPORTS \"$Path\" 2>\"$TMP_DIR/null\" |");
abi-compliance-checker.pl:18859: open(APP, "$ReadelfCmd -Ws \"$Path\" 2>\"$TMP_DIR/null\" |");
abi-compliance-checker.pl:19068: $NM .= " -g \"$Lib_Path\" 2>\"$TMP_DIR/null\"";
abi-compliance-checker.pl:19129: open(LIB, "$OtoolCmd -L \"$Lib_Path\" 2>\"$TMP_DIR/null\" |");
abi-compliance-checker.pl:19147: $DumpBinCmd .= " /EXPORTS \"".$Lib_Path."\" 2>$TMP_DIR/null";
abi-compliance-checker.pl:19195: open(LIB, "$DumpBinCmd /DEPENDENTS \"$Lib_Path\" 2>\"$TMP_DIR/null\" |");
abi-compliance-checker.pl:19214: my $Cmd = $ReadelfCmd." -Ws \"$Lib_Path\" 2>\"$TMP_DIR/null\"";
abi-compliance-checker.pl:19305: $Cmd = $ReadelfCmd." -Wd \"$Lib_Path\" 2>\"$TMP_DIR/null\"";
abi-compliance-checker.pl:19836: my $SonameCmd = "$ObjdumpCmd -x \"$Path\" 2>$TMP_DIR/null";
abi-compliance-checker.pl:20814: foreach my $Line (split(/\n/, `$LdConfig -r 2>\"$TMP_DIR/null\"`))
abi-compliance-checker.pl:20839: foreach my $Line (split(/\n/, `$LdConfig -p 2>\"$TMP_DIR/null\"`))
abi-compliance-checker.pl:21199: my $V = `$Cmd -dumpversion 2>\"$TMP_DIR/null\"`;
abi-compliance-checker.pl:21211: my $Machine = `$Cmd -dumpmachine 2>\"$TMP_DIR/null\"`;
abi-compliance-checker.pl:21226: my $Info = `$Cmd $Opt 2>\"$TMP_DIR/null\"`;
This makes it difficult to debug failures when they happen. One failure that I'm hitting often is a failed preprocessor step where either an #include isn't found, or the tool hits an #error for whatever reason. The clear error message that indicates the failure is thrown out. It would be great if these were visible.
Debian sid just made gcc 4.8 the default, with which abi-compliance-checker cannot compile the headers (exit 5).
Considering the following change of an API. We have a function-like macro where a trailing semicolon was removed:
--- serf/trunk/serf_bucket_types.h 2015/12/11 14:41:41 1719434
+++ serf/trunk/serf_bucket_types.h 2015/12/11 14:44:59 1719435
@@ -392,10 +392,10 @@
serf_bucket_alloc_t *allocator);
#define SERF_BUCKET_SIMPLE_STRING(s,a) \
- serf_bucket_simple_create(s, strlen(s), NULL, NULL, a);
+ serf_bucket_simple_create(s, strlen(s), NULL, NULL, a)
#define SERF_BUCKET_SIMPLE_STRING_LEN(s,l,a) \
- serf_bucket_simple_create(s, l, NULL, NULL, a);
+ serf_bucket_simple_create(s, l, NULL, NULL, a)
/* ==================================================================== */
The old version could be used as a "function call" without semicolon, with semicolon (in which case it would expand to a double semicolon), but not as a function argument.
The new version can be used as a function argument, but must also carry a semicolon when called like a function as a single statement. The dev team has noted that this change is not 100% backwards compatible. In fact some calling code itself needed to change:
http://svn.apache.org/viewvc?view=revision&revision=1719435
http://svn.apache.org/viewvc/serf/trunk/test/test_buckets.c?r1=1719435&r2=1719434&pathrev=1719435
A check could be added for all function-like macros as to whether there is a change w.r.t. using them as a function macro, or requiring a trailing semicolon when calling the macro. This could be addressed by trial compilation.
The abi-dumper and abi-compatibility-checker tools provide a way to automatically detect inadvertent ABI changes during releases as with the following:
https://github.com/radcli/radcli/blob/master/Makefile.am#L34
That can be integrated with build systems like travis to run these tests.
However, once the output of a recent abi-dumper is read from an older abi-compliance-checker there can be failures like the following:
https://travis-ci.org/radcli/radcli/builds/122269438
That is, an abi-compliance-checker failure without a real ABI breakage. The one above is going to be common in CI systems since they often contain old software which cannot be really upgraded by the developers.
A possible fix for the future could be for abi-compliance-checker to fail with a special (non-1) error code in case the input from abi-dumper is from an older, unsupported version.
There are some differences in the translation unit dump generated by GCC 4.7 relative to 4.6.1, so the tool should be adapted to a new version of GCC.
Instructions:
Hi Andrey,
I believe I found a bug in the checker. I try to compare two identical dlls' but the checker is complaining they are incompatible.
I have managed to reproduce the error by using only one class. It seems the checker is complaining about the class virtual destructor.
The dll was compiled using VS 2012 compiler and the checker was using GCC 4.7.3 (i686-w64-mingw32).
In the compatibility source report there is a difference between the added and removed symbols name mangling. Some use gcc and some use vs name mangling format.
I have also tried creating a dump of the dlls and I compared those as well. When I compare the dumps the checker shows they are compatible.
Find attached the projects' source files and the compatibility report.
Please let me know if you managed to reproduce the error and what fix I can apply to the checker to get rid of the bug.
Thank you in advance.
Panicos
With version 1.99.14.1, I just noticed a false positive in the HTML report:
Type of return value has been changed from
std::map<std::__cxx11::string,std::__cxx11::string>
to
std::map<std::__cxx11::string, std::__cxx11::string>
Note trailing comma separating the template parameters.
Are there any chance to see illumos support in the checker? Binutils are available here, however, using elfdump could be more preferable.
Hi,
A struct declared inside a class is identified as class on the report file.
Below is an example.
[OLD Version]
class MyClass {
struct MyStruct {
const MyType* myType;
MyStruct() {}
};
};
[NEW Version]
class MyClass {
struct MyStruct {
MyType* myType;
MyStruct() {}
};
};
Then, I got a compatibility report as follows.
Thanks.
Now I try to use python library to generate the XML descriptor file automatically, but it seems that they need the XML file have a root label, I want to know whether we could add a root xml label for the descriptor file or not ?
You can find a patch that fixes this problem here: https://gist.github.com/raphaelh/368714d044209740bc1b
Hi,
I'd love to be able to see changes in the kernel API from one version to the next (very useful for my work), but this tool seems unable to do it.
Have you tried that? I might just be doing it wrong :]
I tried making a simple xml:
<version> 4.2.6 </version>
<headers> x86_64-4.2.6/include/ </headers>
<libs> x86_64-4.2.6/lib/ </libs>But when I try to run it, they all give me the same
Using C++ compatibility mode
ERROR: some errors occurred when compiling headers
"C++ compatibility mode" seems suspicious, and I couldn't find any way to force it to C.
The log file explains a header could not be found:
In file included from /home/eric/dev/kernel/x86_64-4.2.6/include/acpi/platform/aclinux.h:165:0,
from /home/eric/dev/kernel/x86_64-4.2.6/include/acpi/platform/acenv.h:173,
from /home/eric/dev/kernel/x86_64-4.2.6/include/acpi/acpi.h:56,
from /home/eric/.tmp/zCGSkyLpQ5/dump1.h:3:
/home/eric/dev/kernel/x86_64-4.2.6/include/linux/string.h:17:24: fatal error: asm/string.h: No such file or directory
#include <asm/string.h>
^
compilation terminated.
I pretty tired, and wouldn't be surprised if I missed something obvious :)
I am execuing abi-compliance-checker from a Ubuntu 14.04 64b machine with GCC 4.8.4, but I get a warning about GCC 4.8.
I've looked at the source code, and afaik it should only affect versions between 4.8.0 and 4.8.2. The problem is that after the warning it sets EMERGENCY_MODE_48 to 1 and changes the behaviour of ACC.
Is it intended that version 4.8.4 is executed with EMERGENCY_MODE_48 enabled?
Hi,
It seems report here is broken. File does not change.
May be you have discover a g++ bug https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.7-2/6.9.7-3/d679a/abi_compat_report.html
Hi!
I'm using ABICC since version 1.99.1 (and also the latest release 1.99.12), and there was a minor issue in detection the word-size (Function detectWordSize) with our Cross-GCC (i386-elf) - version 4.1.2 and 4.6.4.
Following patch will (IMHO) fix a wrong assumption about 8-Byte word; and with a small speed up:
--- abi-compliance-checker.pl Wed Sep 23 11:26:06 2015
+++ abi-compliance-checker.pl (working copy)
@@ -19670,12 +19670,12 @@
# speed up detection
if(my $Arch = getArch($LibVersion))
{
if($Arch=~/\A(x86_64|s390x|ppc64|ia64|alpha)\Z/) {
- $Size = "8";
+ return "8";
}
elsif($Arch=~/\A(x86|s390|ppc32)\Z/) {
- $Size = "4";
+ return "4";
}
}
if($GCC_PATH)
@@ -19701,7 +19701,7 @@
elsif($Defines=~/ __PTRDIFF_TYPE__\s+(\w+)/)
{ # GCC 3
my $PTRDIFF = $1;
- if($PTRDIFF=~/long/) {
+ if($PTRDIFF=~/long long/) {
$Size = "8";
}
else {
a) The first part (using return) for a "real" speed-up; Ie. following detection isn't needed, if the size is already detected.
b) PTRDIFF_TYPE like 'long unsigned int' (matching long) was interpreted as 8-Byte word; I think, it should be 'long long' and otherwise default to 4-Byte word(s).
Sorry, If the suggested return-statements should return a number instead of string "4" or "8"; I'm not fully familiar with perl :-(
Best regards from Austria,
Markus
Why doesn't it check for source compatibility in -cmp-systems mode?
The tool doesn't work properly with GCC 6.2/6.1 due to GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040.
Current HTML style defines text color, but does not define background color. Because default colors are implementation dependent, it can happen then an HTML viewer will render a black text on a black background. This is the current CSS code from the Report.css:
body {
font-family:Arial, sans-serif;
color:Black;
font-size:14px;
}
Please add a background-color property with a value you think it matches best to colors you are using in the output.
Hi. I'm comparing the API/ABI of a library that had
struct { int x; };
To one that has
struct { union {int x,y}; };
This should be a backwards-compatible change: the old sources can still refer to element 'x' by name and get the right thing. But abi-compliance checker sees this as a rename from 'x' to 'unnamed0', and flags it as an incompatibility.
Can ABI tool recognize .hpp files as header file? I have sys_root and there are .hpp files beside the .h files. Can abi tool build the rpms with those .hpp header files?
Example code showing what we are seeing.
SomeHeader.h
Original:
namespace DummyNamespace
{
int SomeIntFunction();
void SomeVoidFunction();
char SomeCharFunction();
}
Modified:
namespace DummyNamespace
{
int SomeIntFunction();
char SomeCharFunction();
}
SomeHeader.h is listed as being checked on the report but the modified version is not reporting either a source or binary compatibility issue in version 1.99.9 running in 14.04 Ubuntu.
Use JSON (or XML) to generate lighter reports. Currently, HTML reports easily reach 5mb, while XML reports reach 80mb.
Optimize the output of XML or add JSON output format.
The data that takes most amount of bytes is the continuos repetition of phrases like Field power_dependent has been removed from the middle position of this structural type. and the entire Effects table.
When I tried to generate XML report, I found the affected elements in Problems with
Data Types are always empty.
In line 17023, I guess $Kinds_Locations{$TypeName} should be %Kinds_Locations ?
getReportFooter used to take 2 parameters, now it only takes one.
This patch fixes the problem: https://gist.github.com/raphaelh/9617998d7f71648ffb5e
Right now there is no option to specify an output path/file name (or if there is, it doesn't show in the --help).
Add something like --output /path/to/report/name.html
The patch can be found here: https://gist.github.com/raphaelh/8b0a299c67698098e242
In isDump and isDump_U subroutines the regex are not true when the dump file is compressed using zip.
The tool doesn't detect the addition or removal of data member from class. Is there any extra command line switch i need to provide i tried "-lang c++ -use-dumps" these switches.
Hello,
I'm trying to create a dump for a library for which i'm getting an error "error: expected constructor, destructor, or type conversion before ‘(’ token".
This is happening only for the API which is declared as extern in the header file.
How should the extern API declaration need to be handled for ABI dump?
We need an option --skip-namespaces=PATH to provide a file with the list of name-spaces that should not be checked.
I get this
ERROR: can't extract '/Users/deil/code/abi-compliance-checker/abi_dumps/libsample_cpp/libsample_cpp_1.0.abi.tar.gz'
when running abi-compliance-checker --test-dump on Mac.
Is it normal or a problem?
l$ abi-compliance-checker --test-dump
Using GCC 4.7.2 (x86_64-apple-darwin12)
verifying detectable C library changes
preparation, please wait ...
Using GCC 4.7.2 (x86_64-apple-darwin12)
Using GCC 4.7.2 (x86_64-apple-darwin12)
checking header(s) 1.0 ...
checking header(s) 2.0 ...
Using C++ compatibility mode
Using C++ compatibility mode
creating library ABI dump ...
library ABI has been dumped to:
abi_dumps/libsample_c/libsample_c_1.0.abi.tar.gz
you can transfer this dump everywhere and use instead of the 1.0 version descriptor
creating library ABI dump ...
library ABI has been dumped to:
abi_dumps/libsample_c/libsample_c_2.0.abi.tar.gz
you can transfer this dump everywhere and use instead of the 2.0 version descriptor
preparation, please wait ...
x libsample_c_1.0.abi
ERROR: can't extract '/Users/deil/code/abi-compliance-checker/abi_dumps/libsample_c/libsample_c_1.0.abi.tar.gz'
result: SUCCESS (97 problems found)
verifying detectable C++ library changes
preparation, please wait ...
Using GCC 4.7.2 (x86_64-apple-darwin12)
Using GCC 4.7.2 (x86_64-apple-darwin12)
checking header(s) 1.0 ...
checking header(s) 2.0 ...
WARNING: incompatible version of 'ctags' program
WARNING: incompatible version of 'ctags' program
creating library ABI dump ...
creating library ABI dump ...
library ABI has been dumped to:
abi_dumps/libsample_cpp/libsample_cpp_1.0.abi.tar.gz
you can transfer this dump everywhere and use instead of the 1.0 version descriptor
library ABI has been dumped to:
abi_dumps/libsample_cpp/libsample_cpp_2.0.abi.tar.gz
you can transfer this dump everywhere and use instead of the 2.0 version descriptor
preparation, please wait ...
x libsample_cpp_1.0.abi
ERROR: can't extract '/Users/deil/code/abi-compliance-checker/abi_dumps/libsample_cpp/libsample_cpp_1.0.abi.tar.gz'
result: SUCCESS (193 problems found)
I'm seeing this with version 1.99.9-2 on Ubuntu Wily with gcc 5.2.1.
I'm comparing ABIs for a large C++ library. Dumping the new ABI works fine, but comparing against the old one causes abi-compliance-checker to consume more and more memory until it finally dies at around 28 GB of virtual memory.
Here are links to the files. (I can't attach those files because they are the wrong type.)
Old ABI dump: https://www.dropbox.com/s/fh7bk0kmj5fb3qd/libunity-scopes_1.0.0.abi.tar.gz?dl=0
New ABI dump: https://www.dropbox.com/s/tsuaay3xfvqy390/libunity-scopes_1.0.2.abi.tar.gz?dl=0
XML file: https://www.dropbox.com/s/r8j5yltdsl8apsr/abi.xml?dl=0
I'd appreciate any help with this, abi-compliance-checker is a really crucial tool for us.
Suppose I a module and with following SDK headers:
SDK
|--whatever.h
Then in next build I changed it's header file's location with adding a sub folder.
SDK
|--Visual
---|-whatever.h
Do you think this is source compatible?
From Thiago Macieira's document Source compatibility means:
Two libraries are source compatible with each other if:
• Source code written against one will compile without changes
against the other.
However when using ABI checker the tool reported this case is source compatible. Is this right? or I used the tool incorrectly?
Hi,
when working on windows and check a project, it reported below error and compilation terminated. Any ideas on how to fix this? in this project I have a file which #include
In file included from c:/program files (x86)/microsoft visual studio 14.0/vc/include/xstddef:9:0,
from c:/program files (x86)/microsoft visual studio 14.0/vc/include/limits:11,
from c:/program files (x86)/microsoft visual studio 14.0/vc/include/xmemory0:8,
from c:/program files (x86)/microsoft visual studio 14.0/vc/include/xmemory:6,
from c:/program files (x86)/microsoft visual studio 14.0/vc/include/xtree:6,
from c:/program files (x86)/microsoft visual studio 14.0/vc/include/set:6,
from ....._change_key_util.h:12,
from C:\Users\zhuda\AppData\Local\Temp\BUg6m1mPNc/dump1.h:253:
c:/program files (x86)/microsoft visual studio 14.0/vc/include/initializer_list:16:8: fatal error: definition of std::initializer_list does not match #include <initializer_list>
class initializer_list
^~~~~~~~~~~~~~~~
compilation terminated.
Latest release (1.99.9) was more than a year and half ago, several bugfixes and commits happened since then.
For downstream packagers, it would be easier if you could consider tagging a new release incorporating all of those.
When using the -dump-system option, "skip_headers" and "skip_includes" sections in the system descriptors are not respected.
The resulting library descriptors generated don't include "skip_headers" and "skip_includes" sections
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.