Bug #1473
isystem not working as expected
Description
Anna reports that with her new computer compilation of CoCoALib has trouble with GMP.
Investigation showed that -isystem $(EXTLIBS)/include is not working as hoped/expected.
Investigate and correct.
History
#1
Updated by John Abbott over 3 years ago
Updated by This may be related: I thought I had installed GMP 6.2.0 on my computer, but when I compile CoCoA reports that 6.1.2 was used.
UPDATE it seems that I compiled but did not install 6.2.0.
#2
Updated by John Abbott over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
A quick search on internet suggests that the -isystem flag is a "non-standard" feature of some compilers: g++ and clang both have it.
The documentation for clang could be clearer. I wonder...
do we need to specify the path with -Idir and then separately -isystem dir?
Would this solve the problem?
UPDATE: specifying both -I and -isystem seemed to work for me (Linux, g++).
#3
Updated by John Abbott over 3 years ago
- % Done changed from 10 to 20
Anna? is this better for you now?
I'm pretty sure I must have checked in the change mentioned here. Do you still have some trouble with GMP?
#4
Updated by Anna Maria Bigatti over 3 years ago
Updated by Still problematic
Using GMP version 6.2.0: library is in /Users/bigatti/0.99/gmp-6.2.0/.libs/libgmp.a header is in /Users/bigatti/0.99/gmp-6.2.0/gmp.h
with
isystem I get
In file included from utils-gmp.C:19:
In file included from ../../include/CoCoA/utils-gmp.H:21:
In file included from /usr/local/include/gmp.h:50:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cstddef:49:9: error:
no member named 'ptrdiff_t' in the global namespace
using ::ptrdiff_t;
~~^
#5
Updated by John Abbott over 3 years ago
I wonder if we should be using extern "C" when including the gmp header (but not the gmpxx header). -- NO!! (see next comment)
#6
Updated by John Abbott over 3 years ago
I have done a little checking.
The GMP header is automatically C++ safe: it contains all necessary extern "C" declarations, so we do not need to use extern "C" ourselves (and it may even be harmful to do so).
I notice that the error message Anna reported says that she configured with her own "private" version of GMP, but the compiler says that it included a system header (from /usr/local/include/gmp.h).
Something is wrong here!!
@Anna: can you investigate why the compiler includes the wrong header file?
#7
Updated by John Abbott about 3 years ago
Anna: can you check whether this is still a problem?
I suppose it is, but since I do not have access to your Mac, you'll have to investigate.
#8
Updated by John Abbott about 3 years ago
Any update?
#9
Updated by John Abbott almost 3 years ago
- % Done changed from 20 to 30
2021-04-30 we have just verified that this is still a problem when using clang on MacOS.
The solution seems to be to use -I instead of -isystem.
Perhaps this can be done via a shell variable (say ISYSTEM) whose default value is"isystem", but when using clang on MacOS it is set to I... would that work?
#10
Updated by John Abbott almost 3 years ago
How to test of the compiler is clang?
Is it enough just to check that the OS is MacOS?
#11
Updated by John Abbott almost 3 years ago
- % Done changed from 30 to 40
I have a first prototype. Works on my Linux box (but hen it also worked before...)
I'll ask Anna to check on her computer.
#12
Updated by John Abbott almost 3 years ago
- Status changed from In Progress to Feedback
- Assignee set to John Abbott
- % Done changed from 40 to 90
Anna says it works.
It is just a cheap hack: if uname gives Darwin then it uses -I instead of -isystem.
#13
Updated by John Abbott over 2 years ago
- Status changed from Feedback to Closed
- % Done changed from 90 to 100
- Estimated time set to 2.51 h