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