jacobnavia
2017-07-25 23:16:12 UTC
My micro-sd card is very slow. I bought a faster one and downloaded a
newer version of the linux system (debian) for ARM.
I installed the system in my mac, and then uploaded the backups, and
restored /home/jacob. Add a new user, etc.
Then I started to compile my compiler with itself to see if everything
was OK.
And no. In the file "table.c" my compiler (the preprocessor) exploded with
"Includes too deeply nested in signal.h line 1, from signal.h line 1,
from ... etc. Always in the first line.
Weird.
Never had that bug before. After some fiddling (WHICH "signal.h" is
using?) I found it in the first include directory got with
echo | gcc -E -Wp,-v -
Easy.
The "signal.h" is one line long. It says
#include <signal.h>
Ahhhh, ok. My compiler is not stupid. Someone is stupid though, since I
do not see the utility of writing such a file.
What gives?
I remember what people always told me. Do not change the gcc version.
True!
Apparently something has changed, and now gcc uses that file to mean
that the compiler should go to the next path in the list of include
paths and search there for another signal.h
My compiler (stupid as it is) just searches FIRST in the directory where
it was working, instead of going up the ladder.
Anyway gcc seems to find a way of interpreting that file without much
trouble.
What could it be?
Because a simple going up the ladder will not work. You surely could
have several include files in the same directory, and if you search only
in the next, the compiler would never find them.
So, maybe gcc goes up the ladder if and only if the name of the include
file is the same as the current file being compiled?
The problem is that I did not write my own set of includes, and I do not
have the budget of gcc to rewrite all unix includes.
Now, wouldn't be a good idea to make a compiler independent set of
include files that would contain only the required declarations and
nothing compiler specific?
The little C compiler (lcc) is small. It doesn't require any __builtin
whatever. Since I control the compiler, it means I have to write just
"signal.h" in the ~/home/jacob/include directory and the bug is solved.
Since I look there first... no problems.
But this idea of writing a single line file... Maybe the file is longer
and I have some data loss with the faster micro-sd card?
Is this just a hardware problem?
Has anyone seen this file in his/her gcc installation?
I tested with apt-get and it refuses to change anything telling me I
have the latest version of the gcc package. Is there a different package
for getting the gcc includes?
And there is another directory in the gcc path that is called "fixed"
includes.
newer version of the linux system (debian) for ARM.
I installed the system in my mac, and then uploaded the backups, and
restored /home/jacob. Add a new user, etc.
Then I started to compile my compiler with itself to see if everything
was OK.
And no. In the file "table.c" my compiler (the preprocessor) exploded with
"Includes too deeply nested in signal.h line 1, from signal.h line 1,
from ... etc. Always in the first line.
Weird.
Never had that bug before. After some fiddling (WHICH "signal.h" is
using?) I found it in the first include directory got with
echo | gcc -E -Wp,-v -
Easy.
The "signal.h" is one line long. It says
#include <signal.h>
Ahhhh, ok. My compiler is not stupid. Someone is stupid though, since I
do not see the utility of writing such a file.
What gives?
I remember what people always told me. Do not change the gcc version.
True!
Apparently something has changed, and now gcc uses that file to mean
that the compiler should go to the next path in the list of include
paths and search there for another signal.h
My compiler (stupid as it is) just searches FIRST in the directory where
it was working, instead of going up the ladder.
Anyway gcc seems to find a way of interpreting that file without much
trouble.
What could it be?
Because a simple going up the ladder will not work. You surely could
have several include files in the same directory, and if you search only
in the next, the compiler would never find them.
So, maybe gcc goes up the ladder if and only if the name of the include
file is the same as the current file being compiled?
The problem is that I did not write my own set of includes, and I do not
have the budget of gcc to rewrite all unix includes.
Now, wouldn't be a good idea to make a compiler independent set of
include files that would contain only the required declarations and
nothing compiler specific?
The little C compiler (lcc) is small. It doesn't require any __builtin
whatever. Since I control the compiler, it means I have to write just
"signal.h" in the ~/home/jacob/include directory and the bug is solved.
Since I look there first... no problems.
But this idea of writing a single line file... Maybe the file is longer
and I have some data loss with the faster micro-sd card?
Is this just a hardware problem?
Has anyone seen this file in his/her gcc installation?
I tested with apt-get and it refuses to change anything telling me I
have the latest version of the gcc package. Is there a different package
for getting the gcc includes?
And there is another directory in the gcc path that is called "fixed"
includes.