jacobnavia
2017-03-24 10:25:14 UTC
Hi
I am starting to get results with my ARM64 port. lcc-win is compiling
big programs now, without any problems...
The acid test is to compile the compiler with itself. To do that, I need
to parse the includes furnished by the linux system/gcc. There is a
confusing mixture of include files in
/usr/include,
/usr/include/aarch64/bits,
/usr/local/include/aarch64,
and a LONG list of "places" where includes with the same name are stored.
Which one should I use? How could I figure out which ones are used by gcc?
To avoid these problems, I decided to move the includes I am using from
windows to linux, but that would mean that I port my standard C library
into linux, not an easy task, specially because the source code is 100%
adapted to lcc and not easily used by other compilers, and that could
introduce a new set of bugs!
Besides, this produces binary incompatibilities between the generated
code and what the functions in the library expect, even more trouble...
So, I have no other choice than to parse include files full of "gccisms"
and to make that work, and that starts with figuring out WHICH include
files should I use, hence my question in the subject line.
The standard is silent on this subject, not even specifying a common
command that all compilers could support, telling the user how the
search paths are built.
I am starting to get results with my ARM64 port. lcc-win is compiling
big programs now, without any problems...
The acid test is to compile the compiler with itself. To do that, I need
to parse the includes furnished by the linux system/gcc. There is a
confusing mixture of include files in
/usr/include,
/usr/include/aarch64/bits,
/usr/local/include/aarch64,
and a LONG list of "places" where includes with the same name are stored.
Which one should I use? How could I figure out which ones are used by gcc?
To avoid these problems, I decided to move the includes I am using from
windows to linux, but that would mean that I port my standard C library
into linux, not an easy task, specially because the source code is 100%
adapted to lcc and not easily used by other compilers, and that could
introduce a new set of bugs!
Besides, this produces binary incompatibilities between the generated
code and what the functions in the library expect, even more trouble...
So, I have no other choice than to parse include files full of "gccisms"
and to make that work, and that starts with figuring out WHICH include
files should I use, hence my question in the subject line.
The standard is silent on this subject, not even specifying a common
command that all compilers could support, telling the user how the
search paths are built.