Cannot build Newlib on a Linux PC

[R. Diez via newlib]

Hi all:

I already asked this question here before, but got no answer at all:

https://sourceware.org/ml/newlib/2018/msg00794.html

I am getting desperate. I created a 32-bit (i686) Ubuntu MATE virtual
machine for the sole purpose of building Newlib, in case it was getting
confused because of the 64/32-bit multiarch, but it is failing in the
same place.

I am using the latest snapshot: newlib-3.0.0.20180831

This is my configure command:

./configure --prefix="$HOME/rdiez/newlib/newlib-bin"
CFLAGS_FOR_TARGET="-save-temps -g -O0 -DDEBUG"
CXXFLAGS_FOR_TARGET="-save-temps -g -O0 -DDEBUG"
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --disable-multilib
--disable-shared --with-newlib

Compilation is failing like this:

Making all in argz
make[5]: Entering directory
'/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/i686-pc-linux-gnu/newlib/libc/argz'
/bin/bash ../libtool --tag=CC --mode=compile gcc
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.0.0\" -DPACKAGE_STRING=\"newlib\ 3.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -I../../../.././newlib/libc/argz -fno-builtin
-Wall -DHAVE_FCNTL -DHAVE_GETOPT -D_NO_POSIX_SPAWN -fPIC
-D_I386MACH_NEED_SOTYPE_FUNCTION -DMISSING_SYSCALL_NAMES
-DHAVE_INIT_FINI -save-temps -g -O0 -DDEBUG -c -o argz_add.lo
../../../.././newlib/libc/argz/argz_add.c
libtool: compile: gcc
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.0.0\" "-DPACKAGE_STRING=\"newlib 3.0.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -I../../../.././newlib/libc/argz -fno-builtin
-Wall -DHAVE_FCNTL -DHAVE_GETOPT -D_NO_POSIX_SPAWN -fPIC
-D_I386MACH_NEED_SOTYPE_FUNCTION -DMISSING_SYSCALL_NAMES
-DHAVE_INIT_FINI -save-temps -g -O0 -DDEBUG -c
../../../.././newlib/libc/argz/argz_add.c -o argz_add.o
In file included from
/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include/sys/reent.h:13:0,
from
/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include/sys/errno.h:11,
from
/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include/errno.h:9,
from
/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include/argz.h:10,
from ../../../.././newlib/libc/argz/argz_add.c:7:
/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include/_ansi.h:72:19:
error: missing binary operator before token "("
#if __GNUC_PREREQ (3, 1)
^
Makefile:390: recipe for target 'argz_add.lo' failed
make[5]: *** [argz_add.lo] Error 1


It looks like it does not know macro __GNUC_PREREQ. But the right
#includes are apparently there.

I am not the only one facing problems trying to build Newlib for a Linux PC:

https://stackoverflow.com/questions/49925014/how-do-i-build-newlib-for-x86-and-x86-64-linux-in-a-x86-64-linux-host

Please can somebody help?

Best regards,
rdiez

[Jeff Johnston]

Hello,

The linux build for newlib is a very delicate thing. It works using an
amalgamation of headers from newlib and from your local glibc. This is
required because some of the source code in libc/sys/linux is taken from
glibc and cannot compile with newlib's headers alone.
It consistently breaks release to release due to changes in the glibc
headers.

That said, the linux build hasn't been updated in a long while as no one
has indicated they are using it (re: no reports of problems). It is out of
date with what newlib has added since the last time it was updated.
Patches are welcome.

You will notice that the libc/sys/linux directory has an include directory
and a sys directory. These are header files that complement and
override newlib's. One such case is sys/feature.h which is where the
__GNUC_PREREQ macro is now defined in newlib.

I would suggest you look at adding the missing stuff from newlib's
sys/features.h to libc/sys/linux/sys/features.h. If you look at
/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include
you can see what headers are in place (e.g.
you should see the bare bones sys/features.h from libc/sys/linux/sys)

That should fix your immediate problem but you may run into other header
issues that you will need to similarly patch.

-- Jeff J.

Post by R. Diez via newlib
https://sourceware.org/ml/newlib/2018/msg00794.html
I am getting desperate. I created a 32-bit (i686) Ubuntu MATE virtual
machine for the sole purpose of building Newlib, in case it was getting
confused because of the 64/32-bit multiarch, but it is failing in the same
place.
I am using the latest snapshot: newlib-3.0.0.20180831
./configure --prefix="$HOME/rdiez/newlib/newlib-bin"
CFLAGS_FOR_TARGET="-save-temps -g -O0 -DDEBUG"
CXXFLAGS_FOR_TARGET="-save-temps -g -O0 -DDEBUG" --host=i686-pc-linux-gnu
--target=i686-pc-linux-gnu --disable-multilib --disable-shared
--with-newlib
Making all in argz
make[5]: Entering directory '/home/rdiez/rdiez/newlib/newl
ib-3.0.0.20180831/i686-pc-linux-gnu/newlib/libc/argz'
/bin/bash ../libtool --tag=CC --mode=compile gcc
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.0.0\" -DPACKAGE_STRING=\"newlib\ 3.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-I. -I../../../.././newlib/libc/argz -fno-builtin -Wall -DHAVE_FCNTL
-DHAVE_GETOPT -D_NO_POSIX_SPAWN -fPIC -D_I386MACH_NEED_SOTYPE_FUNCTION
-DMISSING_SYSCALL_NAMES -DHAVE_INIT_FINI -save-temps -g -O0 -DDEBUG -c
-o argz_add.lo ../../../.././newlib/libc/argz/argz_add.c
libtool: compile: gcc -I/home/rdiez/rdiez/newlib/new
lib-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include
-I/home/rdiez/rdiez/newlib/newlib-3.0.0.20180831/newlib/libc/include
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.0.0\" "-DPACKAGE_STRING=\"newlib 3.0.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-I. -I../../../.././newlib/libc/argz -fno-builtin -Wall -DHAVE_FCNTL
-DHAVE_GETOPT -D_NO_POSIX_SPAWN -fPIC -D_I386MACH_NEED_SOTYPE_FUNCTION
-DMISSING_SYSCALL_NAMES -DHAVE_INIT_FINI -save-temps -g -O0 -DDEBUG -c
../../../.././newlib/libc/argz/argz_add.c -o argz_add.o
In file included from /home/rdiez/rdiez/newlib/newli
b-3.0.0.20180831/newlib/libc/include/sys/reent.h:13:0,
from /home/rdiez/rdiez/newlib/newli
b-3.0.0.20180831/i686-pc-linux-gnu/newlib/targ-include/sys/errno.h:11,
from /home/rdiez/rdiez/newlib/newli
b-3.0.0.20180831/newlib/libc/include/errno.h:9,
from /home/rdiez/rdiez/newlib/newli
b-3.0.0.20180831/newlib/libc/include/argz.h:10,
error: missing binary operator before token "("
#if __GNUC_PREREQ (3, 1)
^
Makefile:390: recipe for target 'argz_add.lo' failed
make[5]: *** [argz_add.lo] Error 1
It looks like it does not know macro __GNUC_PREREQ. But the right
#includes are apparently there.
https://stackoverflow.com/questions/49925014/how-do-i-build-
newlib-for-x86-and-x86-64-linux-in-a-x86-64-linux-host
Please can somebody help?
Best regards,
rdiez

[R. Diez via newlib]

The linux build for newlib is a very delicate thing.  It works using an
[...]

Thanks for the information.

If we leave the Linux builds aside, what is the fastest way to test
changes in Newlib? Is there a simulator for an embedded system that is
fast to start up?

I am working on a ARM Cortex-M4F microcontroller, and flashing a new
firmware takes a long time. I would prefer some sort of ARM Cortex
simulator.


By the way, I am surprised that Newlib breaks this way and nobody
notices. Does the Newlib team run some kind of automated tests before
each release/snapshot?

I know the autotools and I could contribute some improvements. But I
fear that I could break things and not realise. I do not have a baseline
at the moment to test against.

Best regards,
rdiez

[Jeff Johnston]

Post by Jeff Johnston
The linux build for newlib is a very delicate thing. It works using an

[...]

Thanks for the information.
If we leave the Linux builds aside, what is the fastest way to test
changes in Newlib? Is there a simulator for an embedded system that is fast
to start up?
I am working on a ARM Cortex-M4F microcontroller, and flashing a new
firmware takes a long time. I would prefer some sort of ARM Cortex
simulator.
By the way, I am surprised that Newlib breaks this way and nobody notices.
Does the Newlib team run some kind of automated tests before each
release/snapshot?

A snapshot is just a snapshot.

The Linux code was a hack - it is outside the shared newlib model and is so
reliant on the local glibc. There are better alternatives for a full C
library on Linux such as glibc itself.
I had originally thought of copying more of glibc over to prevent the
release to release issues, but it is a lot of work and nobody was using it.

Regarding normal platforms, my testing has in the past used the mn10300
simulator which I built myself from a combined source tree. I'm sure the
ARM folks
can point you to something for ARM.

Post by Jeff Johnston
I know the autotools and I could contribute some improvements. But I fear
that I could break things and not realise. I do not have a baseline at the
moment to test against.
Best regards,
rdiez

[Keith Packard]

Post by R. Diez via newlib
https://sourceware.org/ml/newlib/2018/msg00794.html
I am getting desperate. I created a 32-bit (i686) Ubuntu MATE virtual
machine for the sole purpose of building Newlib, in case it was getting
confused because of the 64/32-bit multiarch, but it is failing in the
same place.

I ended up creating a parallel meson-based build system to replace the
aging autotools infrastructure. Now I can build newlib in 64-bit mode
too for testing. It doesn't have syscall support, so it's not an
actually useful library, but I've kludged enough stuff to test
printf/scanf

https://keithp.com/cgit/newlib.git/