More parse madness

paulf

"could not parse"

The conflicts are on lines 74 and 79

So __BYTE_ORDER is both little and big endian at the same time.

Back to the same file

'omp.h' file not found.

But F2 can open it.

Paul Colby

HI @paulf,

So __BYTE_ORDER is both little and big endian at the same time.

Well, more precisely, it would indicate that __BYTE_ORDER, __BIG_ENDIAN and __LITTLE_ENDIAN are all set to the same value (possibly nothing at all).

Where are those macros being defined?

Cheers.

paulf

@Paul-Colby Sorry for being a bit slow. The file is /usr/include/bits/waitstatus.h (on CentOS 7.9).

What are the values of __BYTE_ORDER __LITTLE_ENDIAN and __BIG_ENDIAN? A bit tricky. If I open waitstatus.h then that block declaring 'union wait' is greyed out due to an "#ifdef __USE_BSD" block.

I can't say that I have much confidence that what I see in the GUI corresponds to what the code parser is doing. But here we go,

This gets included from /usr/include/stdlib.h.

#if (defined __USE_XOPEN || defined __USE_XOPEN2K8) && !defined _SYS_WAIT_H
/* XPG requires a few symbols from <sys/wait.h> being defined.  */
# include <bits/waitflags.h>
# include <bits/waitstatus.h>

features.h says that _GNU_SOURCE is defined. F2 can't find where that gets defined.

bits/endian.h has

#define __BYTE_ORDER __LITTLE_ENDIAN

And endian.h has

#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN 4321
#define __PDP_ENDIAN 3412

/* This file defines `__BYTE_ORDER' for the particular machine. */
#include <bits/endian.h>

I can't see anywhere that we are redefining these.

Ah ha! I just found the problem.

Since this is an "imported existing project" the Creator "files" and "includes" are simply whatever got found in the filesystem. In particular "includes" bears almost no resemblance to what the compiler sees in terms of "-I" arguments.

We have a copy of boost in our repo, and "include/boost/predef/other" includes another "endian.h"

I presume that the code parser was picking that one up rather than the one in /usr/include.

Why boost couldn't have called the file "boost_endian.h" is beyond me.

After commenting out the path in "includes" things are a little bit better.

Now, why can't it find omp.h?

Adding the include path to my GCC build in "includes" seems to have fixed that.

Now I'm just getting failures due to our bad code. Stuff like C++ incompatibilities with C and overloads hiding base virual functions.