libgcc2.c includes limits.h without need

[Wookey]

gcc stage1 build configured with --without headers fails during (static) libgcc build due to including limits.h, which is only present in build arch versions at this point. This only seems to actually crop up in the Debian/Ubuntu packaging, probably because of multiarch file layouts. (The build completes if any version of bits/predefs.h is found anywhere, such as /usr/include, which will normally be the case on a mahcine with libc6-dev installed -that it is for the wrong arch doesn't actually seem to matter in this case).

The error is:
/home/wookey/linaro/armv8/toolchain/raringnew/arm64-cross-toolchain-base-1.92/gcc/build/./gcc/xgcc -B/home/wookey/linaro/armv8/toolchain/raringnew/arm64-cross-toolchain-base-1.92/gcc/build/./gcc/ -B/usr/aarch64-linux-gnu/bin/ -B/usr/aarch64-linux-gnu/lib/ -isystem /usr/aarch64-linux-gnu/include -isystem /usr/aarch64-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -DHAVE_CC_TLS -o _fixunsxfsi.o -MT _fixunsxfsi.o -MD -MP -MF _fixunsxfsi.dep -DL_fixunsxfsi -c ../../../src/libgcc/libgcc2.c
In file included from /usr/include/features.h:341:0,
                 from /usr/include/limits.h:26,
                 from /home/wookey/linaro/armv8/toolchain/raringnew/arm64-cross-toolchain-base-1.92/gcc/build/./gcc/include-fixed/limits.h:169,
                 from /home/wookey/linaro/armv8/toolchain/raringnew/arm64-cross-toolchain-base-1.92/gcc/build/./gcc/include-fixed/syslimits.h:7,
                 from /home/wookey/linaro/armv8/toolchain/raringnew/arm64-cross-toolchain-base-1.92/gcc/build/./gcc/include-fixed/limits.h:34,
                 from ../../../src/libgcc/libgcc2.c:1733:
/usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory

Including headers when --without-headers is set should be wrong. Including wrong-arch headers is also wrong. Things could (and possibly should) probably be done to fix that, but in fact it's not actually necessary:

The offending code is in libgcc2.c around 1733:
#if defined(L_fixunsxfsi) && LIBGCC2_HAS_XF_MODE
/* Reenable the normal types, in case limits.h needs them. */
#undef char
#undef short
#undef int
#undef long
#undef unsigned
#undef float
#undef double
#undef MIN
#undef MAX
#include <limits.h>

UWtype
__fixunsxfSI (XFtype a)
{
  if (a >= - (DFtype) Wtype_MIN)
    return (Wtype) (a + Wtype_MIN) - Wtype_MIN;
  return (Wtype) a;
}
#endif

That inclusion of limits.h was there because the function __fixunsxfSI used to use LONG_MIN from that headers file, but this was changed a while back (http://repo.or.cz/w/official-gcc.git/blobdiff/49f0f270673c4512c11f72a038b84c321ae5534a..7429c938827aa98bf3b02c4ac89510f4d28ef0b1:/gcc/libgcc2.c)
to use Wtype_MIN instead, which is defined in the local libgcc2.h header.

so in fact the limits.h inclusion is no longer needed.

The attached patch fixes this for gcc 4.7.2

[Wookey (wookey)]

Here is a patch to fix this for gcc-4.7 in raring.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "gcc-4.7.2-libgcc-no-limits-header.diff" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Matthias Klose (doko)]

So better remove gcc-multilib when building cross packages. This is not an issue on the buildds. Is this patch removing the limits.h includes forwarded upstream?

[Wookey (wookey)]

Now filed upstream as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743

Does libgcc2.c only get built if building gcc-multilib? I thought the libgcc build was happening because we build a static libgcc in DEB_STAGE=stage1 and that that is actually needed? I agree if it's not needed then lets not build it.

I think this works on the buildds because there is a /usr/include/bits/predefs.h installed by some package or other, and if that is present then you see no error, even though a wrong-arch header has been picked up.

Something odd is going on because you end with that file existing, but not owned by dpkg according to dpkg -S /usr/include/bits/predefs.h
libc6-dev-i386 owns the /usr/include/bits dir, and removing it removes the contents.

I defer to experts as to what is the correct fix for all this. As you say the cross-toolchain builds do actually work, but more by luck than actual correctness, so far as I can see.

[Matthias Klose (doko)]

any update?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthias Klose (doko)]

fixed in gcc-4.8 (Ubuntu & Debian), and GCC trunk