Compiler error with U_FORTIFY_SOURCE, D_FORTIFY_SOURCE options
Christian Mauderer
list at c-mauderer.de
Fri May 25 15:51:20 UTC 2018
Am 25.05.2018 um 17:14 schrieb Joel Sherrill:
>
>
> On Fri, May 25, 2018 at 10:09 AM, Amaan Cheval <amaan.cheval at gmail.com
> <mailto:amaan.cheval at gmail.com>> wrote:
>
> Hi!
>
> I don't know the specifics of the thing you're talking about here,
> so others should definitely weigh in on that if they can, but
> regarding the header file; the include syntax used (<ssp.h>, as
> opposed to "ssp.h") is the one used for system header files (for eg.
> <stdio.h> vs "my_header.h").
>
> I see 2 possibilities:
> - The project expects these files to be in a standard include
> directory (such as /usr/include), which the compiler checks for
> system headers by default
> - You need to add the directory where ssp.h exists to the
> command-line flags for the compiler, for eg. through "gcc -I. ssp.c"
> (assuming ssp.c includes ssp.h, which exists in the same directory).
> See this for
> more: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/Search-Path.html
> <https://gcc.gnu.org/onlinedocs/gcc-6.4.0/cpp/Search-Path.html>
>
>
> I don't have an ssp.h on my Centos system and don't think it is a
> standard .h file at all.
> It isn't from POSIX or C Library for sure.
>
> If it is in their source tree, then it should be "ssp.h" (or something
> that picks up the file)
> and the use of <> is broken. It isn't a standard header file.
>
> Change it to "". If it works, submit a patch upstream and cc me on it.
> Hopefully
> they will just accept the patch and it won't be a long discussion.
>
Hello,
I'm not sure whether that is the right location to search for that bug.
Udit and I already had a discussion about this problem before he posted
it to the mailing list. The problem seemed odd for me so I suggested
that he should post it here.
The output that Udit posted here is a little short:
----
sh > LANG=en_US make V=1 CROSS_COMPILE=../../install/rtems/5/bin/arm-rtems5-
../../install/rtems/5/bin/arm-rtems5-gcc -o crc/crc32c-arm64.o
-std=gnu99 -Wwrite-strings -Wall -Wdeclaration-after-statement -g
-ffast-math -D_GNU_SOURCE -include config-host.h -I. -I. -O3
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -DBITS_PER_LONG=32
-DFIO_VERSION='"fio-3.6-37-g1222"' -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DFIO_INTERNAL -DFIO_INC_DEBUG -c crc/crc32c-arm64.c
In file included from
/home/christian/rtems/rtems-bbb/install/rtems/5/arm-rtems5/include/sys/unistd.h:596:0,
from
/home/christian/rtems/rtems-bbb/install/rtems/5/arm-rtems5/include/unistd.h:4,
from
/home/christian/rtems/rtems-bbb/install/rtems/5/arm-rtems5/include/pthread.h:25,
from crc/../os/os.h:7,
from crc/crc32c-arm64.c:2:
/home/christian/rtems/rtems-bbb/install/rtems/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/unistd.h:38:10:
fatal error: ssp.h: No such file or directory
#include <ssp.h>
^~~~~~~
compilation terminated.
make: *** [Makefile:336: crc/crc32c-arm64.o] Error 1
sh >
----
(In case the formatting is lost due to the mail: You can find that
output here too:
https://gist.github.com/c-mauderer/5c4bf432b812b78b18bed859d4a7b59a
So that file is included from unistd.h. If you take a look at the path,
there is suddenly a jump from
install/rtems/5/arm-rtems5/include/sys/unistd.h
to
install/rtems/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/ssp.h
That's really odd because in my install location, there is also a
install/rtems/5/arm-rtems5/include/ssp/ssp.h
with correct include paths. The one in
gcc/arm-rtems5/7.3.0 has a header that says that "This file is part of
GCC" while the other one is derived from a NetBSD one and most likely
the one used in Newlib.
So the big question is: Why is the compiler using the wrong include
file? Note that the ssp.h is only included with the FORTIFY_SOURCE
options that Udit mentioned. I would expect that it happens for any
application that uses these options and includes pthread.h.
Best regards
Christian
>
>
> On Fri, May 25, 2018, 8:08 PM Udit agarwal <dev.madaari at gmail.com
> <mailto:dev.madaari at gmail.com>> wrote:
>
> Hi all,
> While cross-compiling fio for RTEMS, by default in the compiler
> call
>
> -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
>
> options are used which raises the following error:
>
> /home/uka_in/development/benchmark/sandbox/5/lib/gcc/arm-rtems5/7.3.0/include/ssp/unistd.h:38:10:
> fatal error: ssp.h: No such file or directory
> #include <ssp.h>
> ^~~~~~~
> compilation terminated.
> make: *** [crc/crc32c-arm64.o] Error 1
>
> However, ssp.h is in the same folder.
> Without these options, only sys/unistd.h is included and not the
> ssp/unistd.h. Any idea why these compiler opts are raising these
> error?
>
> Also, FIO needs a BSP independent method for determining the
> size of RAM for it's internal working. I'm unable to figure out
> any such implementation. Any help on this too, would be great.
>
> Regards,
> Udit agarwal
> _______________________________________________
> devel mailing list
> devel at rtems.org <mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org <mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
>
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
More information about the devel
mailing list