Discussion:
Changing the gcc version
(too old to reply)
jacobnavia
2017-07-25 23:16:12 UTC
Permalink
Raw Message
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.
jacobnavia
2017-07-25 23:20:18 UTC
Permalink
Raw Message
***@pine64:~/lcc/lccarm64/test$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/4.9/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian/Linaro
4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-libsanitizer --disable-libquadmath
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-arm64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-arm64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-arm64
--with-arch-directory=arm64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch
--enable-checking=release --build=aarch64-linux-gnu
--host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian/Linaro 4.9.2-10)
***@pine64:~/lcc/lccarm64/test$
Rick C. Hodgin
2017-07-25 23:20:19 UTC
Permalink
Raw Message
Help me finish CAlive and it won't be an issue.

Thank you,
Rick C. Hodgin
Keith Thompson
2017-07-26 00:12:21 UTC
Permalink
Raw Message
jacobnavia <***@jacob.remcomp.fr> writes:
[...]
Post by jacobnavia
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.
[...]
Post by jacobnavia
The "signal.h" is one line long. It says
#include <signal.h>
On my system, there are 10 files under /usr/include named "signal.h"
(one of them is a symbolic link to one of the others).

The file
/usr/include/sys/signal.h
is as you describe.

That file would normally be included with

#include <sys/signal.h>

Since /usr/include/sys is not on the default include path, the #include
directive would then include /usr/include/signal.h, which contains the
actual declarations.
Post by jacobnavia
Ahhhh, ok. My compiler is not stupid. Someone is stupid though, since I
do not see the utility of writing such a file.
I don't know, but I speculate that there was a meaningful distinction
between <sys/signal.h> and <signal.h> at one time. I don't see a
reference to <sys/signal.h> in POSIX, but they're two distinct and
non-trivial files on another system I have access to (Solaris 9).
The maintainers of glibc (not gcc) apparently found it convenient
to keep <sys/signal.h> to support software that depends on it,
while making it effectively identical to <signal.h>. (<signal.h>
is of course specified by the C standard, and may contain some
additional declarations to support extensions.)

[...]
Post by jacobnavia
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
Unlikely. It's more likely that /usr/include/sys/signal.h was included
due to a `#include <sys/signal.h>` directive, and the name `<signal.h>`
was then resolved via the normal rules.
Post by jacobnavia
My compiler (stupid as it is) just searches FIRST in the directory where
it was working, instead of going up the ladder.
A #include using the <> syntax will cause the compiler to search in a
sequence of implementation-defined places. The "" syntax causes a
different implementation-defined search; if that search fails, it falls
back to the search used for a <> header. (And "" assumes the header is
an actual file, while <> does not.)

I wouldn't expect a "going up the ladder" rule. In particular, I don't
believe gcc has such a rule.

Including either the current directory, or the directory in which the
current source file lives, in the search sequence for `#include <...>`
is valid as far as the standard is concerned, but I would find it quite
surprising. Apparently the glibc maintainers didn't consider that
possibility. The <> syntax is generally used for system headers, which
would normally be in some system-specific or implementation-specific
location(s). I wouldn't want `#include <stdio.h>` to load a file by
that name in the current directory. If I did want that for some reason,
I'd write `#include "stdio.h"`.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacobnavia
2017-07-26 01:31:57 UTC
Permalink
Raw Message
Post by Keith Thompson
On my system, there are 10 files under /usr/include named "signal.h"
Yes, this is typical for software that has been carefully by layers and
layers.
Post by Keith Thompson
(one of them is a symbolic link to one of the others).
Imagine.
Post by Keith Thompson
The file
/usr/include/sys/signal.h
is as you describe.
Now why could someone possibly write a one line file with a preprocessor
infinite loop?
Keith Thompson
2017-07-26 02:12:22 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Keith Thompson
On my system, there are 10 files under /usr/include named "signal.h"
Yes, this is typical for software that has been carefully by layers and
layers.
Post by Keith Thompson
(one of them is a symbolic link to one of the others).
Imagine.
Post by Keith Thompson
The file
/usr/include/sys/signal.h
is as you describe.
Now why could someone possibly write a one line file with a preprocessor
infinite loop?
You snipped the rest of my followup, in which I explained in some detail
why it *isn't* normally an infinite loop.

Apparently there's a mismatch between some assumptions made by the glibc
maintainers (the package that provides the signal.h files in question)
and the behavior of the compiler you're using.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Philip Lantz
2017-07-28 17:19:17 UTC
Permalink
Raw Message
Post by jacobnavia
Imagine.
Post by Keith Thompson
The file
/usr/include/sys/signal.h
is as you describe.
Now why could someone possibly write a one line file with a preprocessor
infinite loop?
To restate what Keith wrote in his other message:

There is a difference in behavior between
#include "signal.h"
and
#include <signal.h>
The difference is that the former searches more places than the latter.
In particular, the latter normally does not search the current directory.
That is why the file you describe shouldn't cause a preprocessor loop.

However, the directory list to be searched is implementation defined,
so it is allowed for the second form of the include to search the current
directory. Apparently that is what your implementation does. Clearly that
header wasn't written with that possibility in mind.

Philip
jacobnavia
2017-07-28 20:11:20 UTC
Permalink
Raw Message
Post by Philip Lantz
Post by jacobnavia
Imagine.
Post by Keith Thompson
The file
/usr/include/sys/signal.h
is as you describe.
Now why could someone possibly write a one line file with a preprocessor
infinite loop?
There is a difference in behavior between
#include "signal.h"
and
#include <signal.h>
The difference is that the former searches more places than the latter.
In particular, the latter normally does not search the current directory.
That is why the file you describe shouldn't cause a preprocessor loop.
That is irrelevant. If the compiler found that file in some directory
according to some obscure algorithm, finding the C preprocessor command

#include <signal.h>

should find it AGAIN since the file is at the same place.

But that is pure logic, and of course does not apply to some compilers.

There is NO information in that file besides an
#include <signal.h>

What is the point?

Suppose: There is a fixed list of include directories for gcc using the
<> brackets.

If gcc is at all reading that file is because it was found in that list.
OK, then it processes the single line of that file and starts going
through the list AGAIN. And it should find the same file!!!!

jacob
Keith Thompson
2017-07-28 21:18:11 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Philip Lantz
Post by jacobnavia
Imagine.
Post by Keith Thompson
The file
/usr/include/sys/signal.h
is as you describe.
Now why could someone possibly write a one line file with a preprocessor
infinite loop?
There is a difference in behavior between
#include "signal.h"
and
#include <signal.h>
The difference is that the former searches more places than the latter.
In particular, the latter normally does not search the current directory.
That is why the file you describe shouldn't cause a preprocessor loop.
That is irrelevant.
No, it isn't.
Post by jacobnavia
If the compiler found that file in some directory
according to some obscure algorithm, finding the C preprocessor command
#include <signal.h>
should find it AGAIN since the file is at the same place.
Here's what gcc's preprocessor will typically find given certain
#include directives.

#include <signal.h>
"/usr/include/signal.h"

#include <sys/signal.h>
"/usr/include/sys/signal.h"

A directive `#include <signal.h>` will not load "/usr/include/sys/signal.h"
unless the user has explicitly altered the search path (which would be a
bad idea).
Post by jacobnavia
But that is pure logic, and of course does not apply to some compilers.
There is NO information in that file besides an
#include <signal.h>
What is the point?
The point is that if you're using gcc and your source file has:

#include <sys/signal.h>

the preprocessor will load the file "/usr/include/sys/signal.h". It
will then see the `#include <signal.h>` directive in that file and load
"/usr/include/signal.h". Since the header name is specified with <>
rather than "", it will not look in the current directory or in the
directory containing the current header file.

There is a common convention on Unix-like systems to put some headers in
a subdirectory named "sys", and to include the prefix "sys/" in the
#include directive to specify that directory.
Post by jacobnavia
Suppose: There is a fixed list of include directories for gcc using the
<> brackets.
If gcc is at all reading that file is because it was found in that list.
OK, then it processes the single line of that file and starts going
through the list AGAIN. And it should find the same file!!!!
As I'm trying to explain, that's not how it works.

I'm assuming that the file you're talking about, with the single line
`#include <signal.h>`, is "/usr/include/sys/signal.h", or at least is in
a directory named "sys". I don't *think* you actually mentioned that,
but I could have missed it. Can you confirm that?

If a (non-gcc) preprocessor, on seeing `#include <signal.h>` uses a
search path that starts with the directory containing the current file,
it will choke on "/usr/include/sys/signal.h". As I said in my original
followup, that behavior is legal as far as the standard is concerned,
but I find it surprising -- and as you've seen, it doesn't work with the
directory structure created by glibc.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacobnavia
2017-07-29 00:36:15 UTC
Permalink
Raw Message
Post by Keith Thompson
I'm assuming that the file you're talking about, with the single line
`#include <signal.h>`, is "/usr/include/sys/signal.h", or at least is in
a directory named "sys". I don't*think* you actually mentioned that,
but I could have missed it. Can you confirm that?
No, the file is in
/usr/include/aarch64-linux-gnu/sys/signal.h

As I was told, I should start looking for include files in the gcc
specified manner if I want to use the linux system. I get that path with
a processing of the path gcc says it does:

echo | gcc -E -Wp,-v -

yields:
#include <...> search starts here:
/usr/lib/gcc/aarch64-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/aarch64-linux-gnu/4.9/include-fixed
/usr/include/aarch64-linux-gnu
/usr/include

So, gcc supposedly starts looking. The first path doesn't exist in my
machine, the second doesn't exist either, the third exists but no
signal.h, and the fourth contains that file with the infinite loop.

So, the compiler starts processing the only directive of the file.

#include <signal.h>

and should (for the same reasons) not find any signal.h in the first
three paths and arrive AGAIN at the same file.

But it doesn't because... well, the docs are one thing, and what the
program does is in now way related to that.

As I know from windows.

Is it worth spending a lot of time in that?

I just figured up a working signal.h and put it in
~/lcc/include

Problem solved.
bartc
2017-07-29 00:49:14 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Keith Thompson
I'm assuming that the file you're talking about, with the single line
`#include <signal.h>`, is "/usr/include/sys/signal.h", or at least is in
a directory named "sys". I don't*think* you actually mentioned that,
but I could have missed it. Can you confirm that?
No, the file is in
/usr/include/aarch64-linux-gnu/sys/signal.h
As I was told, I should start looking for include files in the gcc
specified manner if I want to use the linux system. I get that path with
echo | gcc -E -Wp,-v -
/usr/lib/gcc/aarch64-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/aarch64-linux-gnu/4.9/include-fixed
/usr/include/aarch64-linux-gnu
/usr/include
How does it get to the sys/ path from that?

Does the include file name actually say <sys/signal.h>?

If so, then when it sees <signal.h> in that file, it will search again,
but this time it should not make it to the sys/ path because sys/ is not
specified.

Do you have a trace of all the places your program actually looks for
(1) the original <...signal.h> file and (2) the <signal.h> file from
sys/signal.h?
--
bartc
j***@verizon.net
2017-07-29 01:32:46 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Keith Thompson
I'm assuming that the file you're talking about, with the single line
`#include <signal.h>`, is "/usr/include/sys/signal.h", or at least is in
a directory named "sys". I don't*think* you actually mentioned that,
but I could have missed it. Can you confirm that?
No, the file is in
/usr/include/aarch64-linux-gnu/sys/signal.h
As I was told, I should start looking for include files in the gcc
specified manner if I want to use the linux system. I get that path with
echo | gcc -E -Wp,-v -
/usr/lib/gcc/aarch64-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/aarch64-linux-gnu/4.9/include-fixed
/usr/include/aarch64-linux-gnu
/usr/include
So, gcc supposedly starts looking. The first path doesn't exist in my
machine, the second doesn't exist either, the third exists but no
signal.h, and the fourth contains that file with the infinite loop.
So, the compiler starts processing the only directive of the file.
#include <signal.h>
and should (for the same reasons) not find any signal.h in the first
three paths and arrive AGAIN at the same file.
Why? It's searching for signal.h, not sys/signal.h, and if won't find signal.h in /usr/include/aarch64-linux-gnu/.
Therefore, it continues searching in /usr/include, and there it does find signal.h.
Post by jacobnavia
But it doesn't because...
I doesn't find it in that directory because
/usr/include/aarch64-linux-gnu/signal.h does not exist. The fact that
/usr/include/aarch64-linux-gnu/sys/signal.h exists, while very important for the first search, is irrelevant to the second one. That's because the first search was for sys/signal.h, while the second was for signal.h.

Key point: that search list does not include sub-directories (since the places to be searched are implementation-defined, it could have included sub-directories, but on the Unix-like systems I'm most familiar with, conventionally, they are not included). The only way to retrieve a header from a sub-directory of a standard search directory is to explicitly include the sub-directory's name in the header name that is passed to #include.
Keith Thompson
2017-07-29 01:59:57 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Keith Thompson
I'm assuming that the file you're talking about, with the single line
`#include <signal.h>`, is "/usr/include/sys/signal.h", or at least is in
a directory named "sys". I don't*think* you actually mentioned that,
but I could have missed it. Can you confirm that?
No, the file is in
/usr/include/aarch64-linux-gnu/sys/signal.h
So as I said, it's in a directory named "sys".

If I recall correctly, the problem is that your compiler
(lcc-something?) went into infinite recursion when processing that
file, whereas gcc has no problem with it. Is that correct?

aarch64 is 64-bit ARM. I don't have tools for that installed on my
system, but the directory layout should be similar to x86_64-linux-gnu,
which I do have.
Post by jacobnavia
As I was told, I should start looking for include files in the gcc
specified manner if I want to use the linux system. I get that path with
echo | gcc -E -Wp,-v -
/usr/lib/gcc/aarch64-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/aarch64-linux-gnu/4.9/include-fixed
/usr/include/aarch64-linux-gnu
/usr/include
So, gcc supposedly starts looking. The first path doesn't exist in my
machine, the second doesn't exist either, the third exists but no
signal.h, and the fourth contains that file with the infinite loop.
The 4th directory gcc searches is
/usr/include/aarch64-linux-gnu
The 1-line file you're complaining about is in
/usr/include/aarch64-linux-gnu/sys
Those are two different directories. When gcc searches
/usr/include/aarch64-linux-gnu, it's not going to dive into the sys
subdirectory unless you tell it to.

Is there *another* file
/usr/include/aarch64-linux-gnu/signal.h
that also consists of just that one line? (I think that there isn't
and shouldn't be, but if there is it's likely that your installation
is messed up.)

What exactly is the include directive in the source file you're
compiling? Is it
#include <signal.h>
or is it
#include <sys/signal.h>
? I think you've indicated previously that it's the former.
Post by jacobnavia
So, the compiler starts processing the only directive of the file.
#include <signal.h>
and should (for the same reasons) not find any signal.h in the first
three paths and arrive AGAIN at the same file.
No, `#include <signal.h>` *should* process a file named "signal.h" that
is *not* in a directory named "sys".
Post by jacobnavia
But it doesn't because... well, the docs are one thing, and what the
program does is in now way related to that.
As far as I can tell from what you've said, gcc is behaving correctly
and consistently.
Post by jacobnavia
As I know from windows.
Is it worth spending a lot of time in that?
I just figured up a working signal.h and put it in
~/lcc/include
Problem solved.
Problem worked around, perhaps.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
David Brown
2017-07-29 16:28:31 UTC
Permalink
Raw Message
Post by jacobnavia
Post by Keith Thompson
I'm assuming that the file you're talking about, with the single line
`#include <signal.h>`, is "/usr/include/sys/signal.h", or at least is in
a directory named "sys". I don't*think* you actually mentioned that,
but I could have missed it. Can you confirm that?
No, the file is in
/usr/include/aarch64-linux-gnu/sys/signal.h
As I was told, I should start looking for include files in the gcc
specified manner if I want to use the linux system. I get that path with
echo | gcc -E -Wp,-v -
/usr/lib/gcc/aarch64-linux-gnu/4.9/include
/usr/local/include
/usr/lib/gcc/aarch64-linux-gnu/4.9/include-fixed
/usr/include/aarch64-linux-gnu
/usr/include
So, gcc supposedly starts looking. The first path doesn't exist in my
machine, the second doesn't exist either, the third exists but no
signal.h, and the fourth contains that file with the infinite loop.
So, the compiler starts processing the only directive of the file.
#include <signal.h>
and should (for the same reasons) not find any signal.h in the first
three paths and arrive AGAIN at the same file.
It should not arrive at the file - because "signal.h" does not exist in
the fourth directory on your list. It should find a different file of
that name (the "real" include file) in the fifth directory.
Post by jacobnavia
But it doesn't because... well, the docs are one thing, and what the
program does is in now way related to that.
Could it be that LCC searches the include paths recursively? That
behaviour would be totally different from gcc and any other compiler I
have used, AFAIK. (I can see how it might be useful sometimes, but it
is not common).

As for documentation, see:

<https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Directory-Options.html>
<https://gcc.gnu.org/onlinedocs/gcc-7.1.0/cpp/Header-Files.html>
Post by jacobnavia
As I know from windows.
Is it worth spending a lot of time in that?
Absolutely - it is very definitely worth spending time here. Otherwise
you risk getting similar problems with other files, or using unexpected
header files.
Post by jacobnavia
I just figured up a working signal.h and put it in
~/lcc/include
Problem solved.
No, problem worked around - not diagnosed or solved. Sometimes a
workaround is good enough, but if you fix the root cause, you will avoid
similar problems later.
Noob
2017-07-30 10:53:24 UTC
Permalink
Raw Message
Post by jacobnavia
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
I think you're confusing #include and #include_next
(the latter being a gcc extension).

https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html
Post by jacobnavia
I tested with apt-get and it refuses to change anything telling me I
have the latest version of the gcc package.
Debian is pretty conservative, as far as upgrades go.
gcc 4.9 was released 3 years ago. Since then, there have
been 3 major releases (5, 6, 7 in 2015, 2016, 2017).
Post by jacobnavia
Is there a different package for getting the gcc includes?
gcc proper doesn't export that many headers:
https://packages.ubuntu.com/xenial/all/libgcc-4.9-dev-armhf-cross/filelist

You're probably thinking of libc6:
https://packages.ubuntu.com/xenial/all/libc6-dev-armhf-cross/filelist

Of course, package management, and what headers a given
implementation exports are not really topical here.

Regards.

Loading...