Am 25.05.2018 um 17:14 schrieb Joel Sherrill: > > > On Fri, May 25, 2018 at 10:09 AM, Amaan Cheval <amaan.che...@gmail.com > <mailto:amaan.che...@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.mada...@gmail.com > <mailto:dev.mada...@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@rtems.org <mailto:devel@rtems.org> > http://lists.rtems.org/mailman/listinfo/devel > <http://lists.rtems.org/mailman/listinfo/devel> > > > _______________________________________________ > devel mailing list > devel@rtems.org <mailto:devel@rtems.org> > http://lists.rtems.org/mailman/listinfo/devel > <http://lists.rtems.org/mailman/listinfo/devel> > > > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel