llvm-gcc builds on 32 bit linux broken

Hi all,

I'm having some trouble building llvm-gcc as of today, with and without
bootstrap.

The error I get is:

/home/kooijman/src/llvm-gcc/obj/./gcc/xgcc
  -B/home/kooijman/src/llvm-gcc/obj/./gcc/
  -B/home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/bin/
  -B/home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/lib/ -isystem
  /home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/include -isystem
  /home/kooijman/src/llvm-gcc/obj/../install/i686-pc-linux-gnu/sys-include -O2
  -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
  -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I.
  -I../../llvm-gcc-4.2-trunk/gcc -I../../llvm-gcc-4.2-trunk/gcc/.
  -I../../llvm-gcc-4.2-trunk/gcc/../include
  -I../../llvm-gcc-4.2-trunk/gcc/../libcpp/include
  -I../../llvm-gcc-4.2-trunk/gcc/../libdecnumber -I../libdecnumber
  -I/home/kooijman/src/llvm-trunk/include -I/home/kooijman/src/llvm-trunk/include
  -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions
  -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \
  -c ../../llvm-gcc-4.2-trunk/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o
In file included from /home/kooijman/src/llvm-gcc/obj/./gcc/include/limits.h:10,
                 from ../../llvm-gcc-4.2-trunk/gcc/tsystem.h:108,
                 from ../../llvm-gcc-4.2-trunk/gcc/crtstuff.c:68:
/usr/include/limits.h:125:26: error: no include path in which to search for limits.h
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/home/kooijman/src/llvm-gcc/obj/gcc

The last known working version is r54156 (just compiled that). The latest rev
(r54208) fails for me. In between there are only merges from Apple GCC 4.2,
with not so very helpful messages.

I would have tried to narrow this down a bit further, but I can't easily check
the commit diffs because the mailling list (archives) are down.

Anyone able to reproduce this (or even, better fix it)?

Gr.

Matthijs

Hi Matthijs,

Sorry for the breakage. I'm not sure what is happening here. Could you
either try TOT or do a binary search now that the mailing lists are
back up?

-bw

I think this error is due to these changes:

Doing diffs in .:
--- ./gsyslimits.h.~1~ 2006-11-26 12:31:50.000000000 -0800
+++ ./gsyslimits.h 2007-04-02 12:37:38.000000000 -0700
@@ -4,5 +4,3 @@
     instead of this text. */

  #define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse */
-#include_next <limits.h>
-#undef _GCC_NEXT_LIMITS_H
--- ./limitx.h.~1~ 2006-11-26 12:31:48.000000000 -0800
+++ ./limitx.h 2007-04-02 13:51:40.000000000 -0700
@@ -1,12 +1,11 @@
  /* This administrivia gets added to the beginning of limits.h
     if the system has its own version of limits.h. */

-/* We use _GCC_LIMITS_H_ because we want this not to match
- any macros that the system's limits.h uses for its own purposes. */
-#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */
-#define _GCC_LIMITS_H_

Try adding:

#define _GCC_LIMITS_H_

to limitx.h like so:

#ifdef _GCC_NEXT_LIMITS_H
+#define _GCC_LIMITS_H_
#include_next <limits.h>
#undef _GCC_NEXT_LIMITS_H

and then testing. A good test would do a -dM -E and seeing if everything is still defined and checking the testcase mentioned in the original email thread.

Hi Mike,

thanks for the suggestion, but this was already fixed by Bill (Discussion
continued in another thread IIRC, sorry for that).

Gr.

Matthijs

I did put in a hack, but it was horrible. It might be a good idea to test out Mike's suggestion to see if it's a better way of doing it.

-bw

Hi Bill,

I did put in a hack, but it was horrible. It might be a good idea to
test out Mike's suggestion to see if it's a better way of doing it.

I just tried building llvm-gcc without your hack, and it still works (even
without the fix Mike suggested).

So, it seems that r54245 can be reverted again?

I didn't test bootstrap, however, but it was failing without bootstrap as well
previously. I won't have time to try bootstrap in the next two weeks, though
(I won't be at work).

Gr.

Matthijs

Hi Matthijs,

I did put in a hack, but it was horrible. It might be a good idea to
test out Mike's suggestion to see if it's a better way of doing it.

I just tried building llvm-gcc without your hack, and it still works (even
without the fix Mike suggested).

So, it seems that r54245 can be reverted again?

I didn't test bootstrap, however, but it was failing without bootstrap as well
previously. I won't have time to try bootstrap in the next two weeks, though
(I won't be at work).

If you're comfortable with taking it out, I'd love to remove it. :slight_smile:
I'll go ahead and revert it. Please do a bootstrap test of it when you
get a chance just as a sanity check.

Thanks!
-bw

I've just tried building r54494 on 64bit linux and had the same (no
include path)
error. Any idea what's happening here?

Thanks,
-David Shipman

No. :frowning: Could you try Mike's suggestion? (Replicated here)

Try adding:

#define _GCC_LIMITS_H_

to limitx.h like so:

#ifdef _GCC_NEXT_LIMITS_H
+#define _GCC_LIMITS_H_
#include_next <limits.h>
#undef _GCC_NEXT_LIMITS_H

and then testing. A good test would do a -dM -E and seeing if
everything is still defined and checking the testcase mentioned in the
original email thread.

Mike's suggestion seems to fix the problem - happy to use it,
although my impression is that it shouldn't be necessary?

-David Shipman

Header files are tricky beasts. :slight_smile: I'll go ahead and apply that to the tree. Thanks for testing it out.

-bw

to limitx.h like so:

#ifdef _GCC_NEXT_LIMITS_H
+#define _GCC_LIMITS_H_
#include_next <limits.h>
#undef _GCC_NEXT_LIMITS_H

This fixes this problem for me on Ubuntu Hardy on x86-64.

John

Okay. I've applied this patch. I hope it helps out. :slight_smile:

-bw

That's right, in a clean world there would be no coupling on the compiler from /usr/include. You can go flame glibc. But, it really isn't quite their fault either, there are insane requirements pushed onto the `vendor' of the headers, and it was engineered to loose. The gcc patch `hacks' around this coupling by preserving the magic (interal implementation detail) `interface' to the header file.