View previous topic :: View next topic |
Author |
Message |
R0b0t1 Apprentice
Joined: 05 Jun 2008 Posts: 264
|
Posted: Tue Feb 20, 2018 9:55 pm Post subject: [SOLVED] Unable to Build Newlib |
|
|
Like the issue with GCC, this is a source error, so I have tried asking on the newlib mailing list. Unfortunately no response yet. Code: | export PATH="$(realpath ./prefix/bin):${PATH-}"
pushd "${DIR_BUILD}/${dname}"
mkdir -p ../../${DIR_PREFIX}/host/${dname}/share/doc
../../source/${dname}/configure \
--host=${HOST} \
--target=${TARGET} \
--prefix=`realpath ../../${DIR_PREFIX}` \
--docdir=`realpath ../../${DIR_PREFIX}/share/doc` \
--enable-newlib-nano-malloc \
--enable-newlib-nano-formatted-io \
--enable-lite-exit \
--enable-newlib-io-c99-formats \
--enable-newlib-io-long-long \
--disable-newlib-atexit-dynamic-alloc \
--disable-newlib-supplied-syscalls \
--enable-newlib-reent-small \
--disable-newlib-fvwrite-in-streamio \
--disable-newlib-fseek-optimization \
--disable-newlib-wide-orient \
--disable-newlib-unbuf-stream-opt \
--enable-newlib-global-atexit \
--enable-newlib-retargetable-locking \
--disable-nls
make -j"${NCPU}" -l"${NCPU}"
make install
|
Gives: Code: | In file included from
/home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/ssp/stdio.h:34:0,
from
/home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/stdio.h:800,
from
../../../../../../source/newlib-3.0.0/newlib/libc/stdio/gets.c:62:
../../../../../../source/newlib-3.0.0/newlib/libc/stdio/gets.c:96:1:
error: expected declaration specifiers or ‘...’ before
‘__builtin_object_size’
gets (char *buf)
^
|
The code is more or less a copy of this. Can anyone spot something I missed? Based on what I know of C, it looks like there is a problem with a macro, but I don't know what it is or why the problem exists (gets.c).
Thanks in advance.
Last edited by R0b0t1 on Sat Feb 24, 2018 6:55 am; edited 1 time in total |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Wed Feb 21, 2018 2:43 am Post subject: |
|
|
gets() was a horrible mistake. It was only removed from the language in C11, but it has never been correct. Personally, I think you should resolve this by removing the definition of gets() entirely. Any breakage that results is a good thing. It will warn you of the existence of programs that try to use this function.
Setting aside how you should never facilitate anyone using this, I concur with your assessment. Your build environment likely made a macro gets() that tries to perform some sanity checks. Could you post the post-processed output of that file, so that we can see how the macro was expanded? |
|
Back to top |
|
|
R0b0t1 Apprentice
Joined: 05 Jun 2008 Posts: 264
|
Posted: Wed Feb 21, 2018 7:55 am Post subject: |
|
|
Thanks Hu, that seemed like something reasonable enough to try, unfortunately: Code: | In file included from /home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/stdio.h:800:0,
from ../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/snprintf.c:22:
../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/snprintf.c:66:1: error: expected declaration specifiers or '...' before numeric constant
snprintf (char *__restrict str,
^
In file included from /home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/ssp/stdio.h:34:0,
from /home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/stdio.h:800,
from ../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/snprintf.c:22:
../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/snprintf.c:66:1: error: expected declaration specifiers or '...' before '__builtin_object_size'
snprintf (char *__restrict str,
^
make[8]: *** [Makefile:1216: lib_a-snprintf.o] Error 1
make[8]: *** Waiting for unfinished jobs....
In file included from /home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/stdio.h:800:0,
from ../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/sprintf.c:572:
../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/sprintf.c:606:1: error: expected declaration specifiers or '...' before numeric constant
sprintf (char *__restrict str,
^
In file included from /home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/ssp/stdio.h:34:0,
from /home/R0b0t1/devel/toolgen/source/newlib-3.0.0/newlib/libc/include/stdio.h:800,
from ../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/sprintf.c:572:
../../../../../../../source/newlib-3.0.0/newlib/libc/stdio/sprintf.c:606:1: error: expected declaration specifiers or '...' before '__builtin_object_size'
sprintf (char *__restrict str,
^
| So it seems like this is a rather serious error. |
|
Back to top |
|
|
Mr. T. Guru
Joined: 26 Dec 2016 Posts: 477
|
Posted: Wed Feb 21, 2018 8:50 am Post subject: |
|
|
Hu wrote: | It will warn you of the existence of programs that try to use this function. |
The linker may warn about deprecated features too.
/Edit: fixed a mistake.
Last edited by Mr. T. on Fri Feb 23, 2018 7:17 am; edited 1 time in total |
|
Back to top |
|
|
Mr. T. Guru
Joined: 26 Dec 2016 Posts: 477
|
Posted: Wed Feb 21, 2018 8:53 am Post subject: |
|
|
R0b0t1, you should provide the needed files to fix errors.
Edition: Sorry, I did not think enough: the source code may be found on the mentioned GitHub.
Hu wrote: | Could you post the post-processed output of that file, so that we can see how the macro was expanded? |
Edition: Oops! I am not competent.
Edition: info -n "(gcc)Object Size Checking" |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Thu Feb 22, 2018 3:06 am Post subject: |
|
|
It looks like all the stdio functions that can be hardened by _FORTIFY_SOURCE are choking here. This suggests that the build environment has enabled source fortification when it should not. Source fortification is to be used when compiling the programs that call stdio, not when compiling stdio itself.
helecho, yes, I am aware of the source, but since his output clearly disagrees with a direct parsing of the source, I believe macro expansion to be a key part of this. Yes, gcc's object size check intrinsics are invoked by the post-processed code, but that doesn't mean gcc is at fault for the failure. (Although, a hardened-by-default gcc might be enabling _FORTIFY_SOURCE, which if not expected by the newlib build system, could cause a failure like this.) |
|
Back to top |
|
|
R0b0t1 Apprentice
Joined: 05 Jun 2008 Posts: 264
|
Posted: Thu Feb 22, 2018 4:44 am Post subject: |
|
|
Hu wrote: | Could you post the post-processed output of that file, so that we can see how the macro was expanded? | Sorry, I missed this part. The issue is not the macro expansion from what I can tell, as it is this declaration specifically. In an older version (second most recent on the newlib FTP site) the same issue exists when the macro is used in the declaration so it may be something else. I tried to add "-save-temps" to the compilation options but have had no luck. Does anyone know a way to make sure the flag is passed to gcc invocations from the Makefile? I've done this before, but it depended heavily on the individual Makefile.
Sorry Hu, I did not see your most recent post - if source fortification is what is the issue, then a faulty macro expansion would make sense.
I was able to find the location and pass "-save-temps," here are gets.i and snprintf.i. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Fri Feb 23, 2018 2:47 am Post subject: |
|
|
That post-processed text looks consistent with having a macro such as Code: | #define gets(X) __gets_chk(X, __bos(X)) | You could try to work around this by disabling source fortification for these files, but this seems to me like a problem with the underlying package. It is using system headers that define these overrides, and is not prepared for the overrides to exist. It should handle the overrides automatically or avoid using these headers. |
|
Back to top |
|
|
R0b0t1 Apprentice
Joined: 05 Jun 2008 Posts: 264
|
Posted: Fri Feb 23, 2018 3:11 am Post subject: |
|
|
I agree. For the time being I have set _FORTIFY_SOURCE=1. This must be done in the target's newlib directory containing the Makefile, if you need to do it by hand. The configuration script does not seem to accept CFLAGS and pass it to the produced Makefiles. |
|
Back to top |
|
|
|