libgcc2.c includes limits.h without need

Bug #1091823 reported by Wookey on 2012-12-18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linaro AArch64 cross-distro work
Linaro GCC
Fix Released
gcc-4.7 (Debian)
Fix Released
gcc-4.7 (Ubuntu)
gcc-4.8 (Ubuntu)

Bug Description

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>

__fixunsxfSI (XFtype a)
  if (a >= - (DFtype) Wtype_MIN)
    return (Wtype) (a + Wtype_MIN) - Wtype_MIN;
  return (Wtype) a;

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 (
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) wrote :
Wookey (wookey) wrote :

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

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.]

tags: added: patch
Matthias Klose (doko) wrote :

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) wrote :

Now filed upstream as

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.

Changed in gcc-4.7 (Debian):
status: Unknown → Confirmed
Matthias Klose (doko) wrote :

any update?

summary: - libgcc2.c includes limits.h, breaking --without-headers bootstrap
+ libgcc2.c includes limits.h without need
Launchpad Janitor (janitor) wrote :

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

Changed in gcc-4.7 (Ubuntu):
status: New → Confirmed
Changed in linaro-aarch64:
importance: Undecided → Medium
status: New → Confirmed
Changed in gcc-4.7 (Debian):
status: Confirmed → Fix Released
Matthias Klose (doko) wrote :

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

Changed in gcc-4.8 (Ubuntu):
status: New → Fix Released
Changed in gcc-4.7 (Ubuntu):
status: Confirmed → Won't Fix
Changed in linaro-aarch64:
status: Confirmed → Fix Released
Victor Chong (vchong) on 2013-12-26
Changed in gcc-linaro:
status: New → Confirmed
Changed in gcc-linaro:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.