Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ABI compliance checker thinks that C is C++ #64

Open
jan-cerny opened this issue Aug 25, 2017 · 4 comments
Open

ABI compliance checker thinks that C is C++ #64

jan-cerny opened this issue Aug 25, 2017 · 4 comments

Comments

@jan-cerny
Copy link

Hello,

I have been using abi-compliance-checker for a long time to check API/ABI compatibility while making an upstream releases of OpenSCAP.

However after I upgraded to Fedora 26, abi-compliance-checker stopped working, because it started to treat the C source code as C++. Unfortunately C++ has some keywords that are not keywords in C, so gcc reports errors. Our code is writen in C.

See this log:
https://paste.fedoraproject.org/paste/zcjCZMUb7IsOwJTRjkk7DA

I have discovered option -cxx-incompatible that looks like solving the problem according to its description. However it mitigates only the error with operator, but not with export keyword.

Option -lang C seems to have no effect, gcc still treats it as C++.

I am using abi-compliance-checker-2.1-1.fc26.noarch on Fedora 26 now.

Last time when it worked correctly was with abi-compliance-checker 1.99.20 on Fedora 24. But Fedora 24 is EOL, and also I don't have it anymore, and on Fedora 26 there's no possibility to downgrade.

Is there any way how to check the C code as C code?

Thank you.
@lvc
Copy link
Owner

lvc commented Aug 29, 2017

Hello,

Actually, the code is always compiled by G++ since -fdump-translation-unit option of GCC is valid for C++ only. The checker tries to replace all C++ keywords in the code to C compatible ones before creating the translation unit dump. And seems there are two problems with the checker:

  1. It doesn't handle 'export' keyword properly
  2. It doesn't detect language of the project properly (not sure)

The first problem is fixed right now by the commit 59e148d. But I cannot identify the second one. Probably this is not the issue. Please try latest versions of the checker from master without -cxx-incompatible option.

Also I recommend you to use ABI Dumper tool instead of creating ABI dumps by ABICC to avoid headers compilation step at all. Like this was done in the ABI Tracker project: https://abi-laboratory.pro/tracker/timeline/openscap/

Thanks for reporting this.

@jan-cerny
Copy link
Author

@lvc Thank you very much. I will check that.

I wasn't aware of ABI tracker. That's awesome project. Good job!

jan-cerny added a commit to jan-cerny/openscap-abi-check that referenced this issue Sep 1, 2017
@jan-cerny
Use ABI dumper to create ABI dumps
2cacc00 
The dumps will be used as an input to ABI compliance checker.
This is new recommended way of checking ABI compliance.
See lvc/abi-compliance-checker#64
This commit resolves issues that we had with old approach
on abi-compliance-checker > 1.99.20.
@jan-cerny jan-cerny mentioned this issue Sep 1, 2017
Merged
@jnpkrn jnpkrn mentioned this issue Jan 4, 2018
Closed
jnpkrn added a commit to jnpkrn/abi-compliance-checker that referenced this issue Jan 8, 2018
@jnpkrn
Fix issue with C-code-compiled-as-C++ from 59e148d
d189b18 
Said commit was meant to fix [Issue#64], but rather introduced new
problem -- when "decltype(nullptr)" was observed (happens on transitive
includes starting with standard C library headers, at least with newer
stdlibc++ as this is how headers are treated by gcc when it's passed
"-x c++-header"), the C-only-detection logic would short-circuit (or
give up) early, leaving C++ compatibility measures off, and in turn,
choking later on when valid C identifiers such as "new" are used
somewhere in the headers of the C project at hand.

This rather simplistic solution masks, item-wise, "decltype(nullptr)"
expression consisting of otherwise C++ compatibility mangling eligible
words, and restores them right after there's no danger this would happen
to them, because they need to be preserved (empirically tested).

[Issue#64] lvc#64

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
jnpkrn added a commit to jnpkrn/abi-compliance-checker that referenced this issue Jan 8, 2018
@jnpkrn
Fix issue with C-code-compiled-as-C++ from 59e148d
6406868 
Said commit was meant to fix [Issue#64], but rather introduced new
problem -- when "decltype(nullptr)" was observed (happens on transitive
includes starting with standard C library headers, at least with newer
stdlibc++ as this is how includes are treated by gcc when it's passed
"-x c++-header"), the C-only-detection logic would short-circuit (or
give up) early, leaving C++ compatibility measures off, and in turn,
choking later on when valid C identifiers such as "new" are used
somewhere in the headers of the C project at hand.

This rather simplistic solution masks, item-wise, "decltype(nullptr)"
expression consisting of otherwise C++ compatibility mangling eligible
words, and restores them right after there's no danger this would happen
to them, because they need to be preserved (empirically tested).

[Issue#64] lvc#64

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
@jnpkrn jnpkrn mentioned this issue Jan 8, 2018
Open
jnpkrn added a commit to jnpkrn/libqb that referenced this issue Jan 10, 2018
@jnpkrn
maint: check abi: fix two issues with abi-compliance-checker/libstdc++
4faa64a 
1. ABICC >= 2 needs to be passed -cxx-incompatible switch because C is
   no longer a default for this tool (used to be vice versa),
   plus current version will stop choking on C vs. C++ (our C code with
   C++ compatibility wrapping being viewed from C++ perspective for the
   purpose of dumping the declared symbols, which somewhat conflicts
   with internal masking of the C++ keywords being used as valid C
   identifiers [yet some instances must not be masked here, see
   lvc/abi-compliance-checker#64) only
  if _also_ something like this is applied:
   lvc/abi-compliance-checker#70

2. since 20246f5, libqb.so no longer poses a symlink to the actual
   version-qualified shared library, but rather a standalone linker
   script, which confuses ABICC, so blacklist that file for the scanning
   purposes explicitly, together with referring to the library through
   it's basic version qualification (which alone, sadly, is not
   sufficient as ABICC proceeds to scan whole containing directory
   despite particular file is specified)

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
jnpkrn added a commit to jnpkrn/libqb that referenced this issue Jan 10, 2018
@jnpkrn
maint: check abi: fix two issues with abi-compliance-checker/libstdc++
ec53fb3 
1. ABICC >= 2 needs to be passed -cxx-incompatible switch because C is
   no longer a default for this tool (used to be vice versa),
   plus current version will stop choking on C vs. C++ (our C code with
   C++ compatibility wrapping being viewed from C++ perspective for the
   purpose of dumping the declared symbols, which somewhat conflicts
   with internal masking of the C++ keywords being used as valid C
   identifiers [yet some instances must not be masked here, see
   lvc/abi-compliance-checker#64) only
  if _also_ something like this is applied:
   lvc/abi-compliance-checker#70

2. since 20246f5, libqb.so no longer poses a symlink to the actual
   version-qualified shared library, but rather a standalone linker
   script, which confuses ABICC, so blacklist that file for the scanning
   purposes explicitly, together with referring to the library through
   it's basic version qualification (which alone, sadly, is not
   sufficient as ABICC proceeds to scan whole containing directory
   despite particular file is specified)

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
jnpkrn added a commit to jnpkrn/libqb that referenced this issue Jan 11, 2018
@jnpkrn
maint: check abi: fix two issues with abi-compliance-checker/libstdc++
e0bc8b1 
1. ABICC >= 2 needs to be passed -cxx-incompatible switch because C is
   no longer a default for this tool (used to be vice versa),
   plus current version will stop choking on C vs. C++ (our C code with
   C++ compatibility wrapping being viewed from C++ perspective for the
   purpose of dumping the declared symbols, which somewhat conflicts
   with internal masking of the C++ keywords being used as valid C
   identifiers [yet some instances must not be masked here, see
   lvc/abi-compliance-checker#64) only
  if _also_ something like this is applied:
   lvc/abi-compliance-checker#70

2. since 20246f5, libqb.so no longer poses a symlink to the actual
   version-qualified shared library, but rather a standalone linker
   script, which confuses ABICC, so blacklist that file for the scanning
   purposes explicitly, together with referring to the library through
   it's basic version qualification (which alone, sadly, is not
   sufficient as ABICC proceeds to scan whole containing directory
   despite particular file is specified)

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
chrissie-c added a commit to ClusterLabs/libqb that referenced this issue Sep 25, 2018
@chrissie-c
UPDATED: doc (ABI comparison) and various other fixes (#324)
d0ec0a6 
* doc: qbarray.h: fix garbled Doxygen markup

* build: follow-up for and fine-tuning of a rushed 6d62b64 commit
  (It made a service as-was, but being afforded more time, this would
  have accompanied that commit right away, for better understanding,
  brevity and uniformity.)

* build: prune superfluous Makefile declarations within tests directory
  There was a significant redundancy wrt. build flags and EXTRA_DIST
  assignment (the latter become redundant as of f6e4042 at latest)
  spread all over the place (vivat copy&paste).  Also, in one instance,
  CPPFLAGS (used) was confused with CFLAGS (meant).

* maint: check abi: fix two issues with abi-compliance-checker/libstdc++
1. ABICC >= 2 needs to be passed -cxx-incompatible switch because C is
   no longer a default for this tool (used to be vice versa),
   plus current version will stop choking on C vs. C++ (our C code with
   C++ compatibility wrapping being viewed from C++ perspective for the
   purpose of dumping the declared symbols, which somewhat conflicts
   with internal masking of the C++ keywords being used as valid C
   identifiers [yet some instances must not be masked here, see
   lvc/abi-compliance-checker#64) only
  if _also_ something like this is applied:
   lvc/abi-compliance-checker#70
2. since 20246f5, libqb.so no longer poses a symlink to the actual
   version-qualified shared library, but rather a standalone linker
   script, which confuses ABICC, so blacklist that file for the scanning
   purposes explicitly, together with referring to the library through
   it's basic version qualification (which alone, sadly, is not
   sufficient as ABICC proceeds to scan whole containing directory
   despite particular file is specified)

* maint: check abi: switch to abi-dumper for creating "ABI dumps"
Beside avoiding issues with abi-compliance-checker in the role of ABI
dumps producer (see the preceding commit), it also seems to generate
more accurate picture (maybe because it expressly requires compiling
with debugging information requested).

* Low: qblist.h: fix incompatibility with C++ & check it regularly

* tests: check_list.c: start zeroing in on the gaps in tests' coverage

* tests: print_ver: make preprocessor emit "note" rather than warning

IIRC, Chrissie asked about this around inclusion of the test at
hand, and it seemed there was no way but to emit a warning to get
something output at all.  Now it turns wrong, and moreover, we
make the code not fixed on GCC specific pragmas, with a bit of
luck, "#pragma message" approach is adopted more widely by compilers.

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>

* Replace ck_assert_uint_eq() with ck_assert_int_eq()
it's not available in check 0.9

* Proper check for C++ compiler (from Fabio)
* add (c) to copyright dates
@vinc17fr
Copy link

There's also the issue that GCC knows _Decimal64 with C, but not with C++.

@vinc17fr
Copy link

vinc17fr commented Jun 11, 2020 •
edited

Concerning the decimal floats, a workaround is to add decimal/decimal in the include_preamble section and the following defines in the defines section:

#define _Decimal32 std::decimal::decimal32
#define _Decimal64 std::decimal::decimal64
#define _Decimal128 std::decimal::decimal128

But abi-compliance-checker should be able to detect the use of C decimal floats automatically and do that in this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lvc @vinc17fr @jan-cerny