MacOSX Leopard gcc-4.2 build problems with coreutils-7.0 and its gnulib

[SciFi]

Hi,

I am in the process of testing Apple's compilers in the
XCode-3.1.1 and iPhone-2.1 SDKs for Leopard.  For each project I
want to have the best overall collection in my /usr/local tree. 
I'd like to see how close we can get to having full 32- & 64-bit
universal binaries for X11 & native apps esp. pan2 newsreader.
I hope to eventually work with MacPorts to bump-up their build
process for each project.  (hey someone's gotta do it ;) )

For this maillist thread:

(0)  I'm building coreutils-7.0 and other GNU projects seemingly
just fine (regular 'make'), after I learned that we had to pass
'--disable-dependency-tracking' to configure when building
so-called 'fat' binaries.  (We can't do gcc -M stuff with -arch
flags together, and I'm not about to go thru the rigamarole of
manually building each arch into a separate subdir then manually
using lipo to join them together.)  I know adding this flag is
the responsibility of the build system, I mention it as possible
related background for the other problems below.


(1)  Regular 'make' finishes okay, then I'll do 'make check'.
The first real problem I had here was linking
coreutils-7.0/gnulib-tests/test-getdate failed because the
makefiles did not include the libiconv libs determined by
configure -- missing symbol '_libintl_gettext'.
I see the snapshot I made a little while ago of gnulib from the
git repo has already fixed this on 2008-10-08, but y'all
apparently don't have this snapshot in your coreutils & findutils
& other projects that use this module (available on the alpha FTP
site).
To fix this in coreutils-7.0 (as proof) I added (in effect)
@LIBINTL@ to line 350 of coreutils-7.0/gnulib-tests/gnulib.mk (as
a quick fix I did the corresponding thing to its Makefile.in and
Makefile).
LIB_CLOCK_GETTIME is empty as generated here.
A patch to add @LIBINTL@ to coreutils-7.0/gnulib-tests tree:
$ diff -ubBEw gnulib-tests/gnulib.mk_orig gnulib-tests/gnulib.mk
--- gnulib-tests/gnulib.mk_orig 2008-10-05 10:08:00 -0500
+++ gnulib-tests/gnulib.mk      2008-11-16 03:26:57 -0600
@@ -347,7 +347,7 @@
 
 TESTS += test-getdate
 check_PROGRAMS += test-getdate
-test_getdate_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
+test_getdate_LDADD = $(LDADD) @LIBINTL@ $(LIB_CLOCK_GETTIME)
 EXTRA_DIST += test-getdate.c
 
 ## end   gnulib module getdate-tests
This part of coreutils-7.0 'make check' will now compile & link
properly.


(2)  The next problem I had with coreutils-7.0 'make check', and
I'm _still_ stuck here:
The compiler bombs when it gets to building
coreutils-7.0/gnulib-tests/test-stdint:
[…]
llvm-gcc-4.2 -std=gnu99  -I. -I../lib  -I. -I. -I.. -I./.. -I../lib -I./../lib 
-I/usr/local/include  -Os -mtune=core2 -march=core2 -force_cpusubtype_ALL       
 -arch i386  -arch x86_64         -c test-stdint.c
test-stdint.c:263: error: negative width in bit-field 
‘verify_error_if_negative_size__’
test-stdint.c:264: error: negative width in bit-field 
‘verify_error_if_negative_size__’
test-stdint.c:263: error: negative width in bit-field 
‘verify_error_if_negative_size__’
test-stdint.c:264: error: negative width in bit-field 
‘verify_error_if_negative_size__’
[…]

The doubled-up error lines are because the module is
automatically being compiled twice: once for each -arch.  (I can
only test on my C2D iMac with maxed-out 4GB RAM; Leopard &
Xcode-3.1.1 etc. are all suppose to be fully 64-bit ready, but
the 32-bit build is stopping here also.)

Unsetting the C(xx)FLAGS makes no difference i.e. a single native
arch build with default flags etc. still causes this error.

Using Apple's regular gcc-4.2 family also produces this error.

The only other available compiler is gcc-4.0 which /does/ work
here, but it's old-hat: we can't tune for the new core2 chips
with it (I've been using nonoca or prescott with it).

Same things happen with find-4.5.2 and other projects that use
gnulib-tests/test-stdint from that particular generation it
seems.

I noted that a very similar error was reported against cygwin
earlier in 2007:
http://lists.gnu.org/archive/html/bug-gnulib/2007-04/msg00090.html
And see more recent related discussions on this list, but those
patches don't seem to cover Apple's newer compilers.

I saw the announcement in the bug-gnulib list, and gave
hello-2.3.91 a try with the llvm compiler suite.  It passed.  But
I don't think it includes running these particular gnulib-tests.


The gnulib git snapshot is suffering other problems trying to
analyze these two problems.  For ex. after using ./gnulib-tool to
create a tempdir and pull getdate with tests into it, the
configure & make steps left @LIBINTL@ empty: that tool isn't
designed to thoroughly test stand-alone cases it seems.  ;)


To wrap this up with obvious questions:

Could we get all the projects at the alpha FTP site that use
gnulib to be refreshed please so they'll get caught-up to the
fixes?  Or will this automatically be done in each project's
git repo as it builds the underlying stuff ("missing" in
their snapshots pulling in needed modules from the latest
gnulib repo)?

Is (2) a bug in Apple's compiler / headers?
Is there a workaround to allow us to use their gcc-4.2?
Maybe getting project snapshots & having them pull latest
gnulib has it fixed already for Apple's compilers/headers?
(google is failing me again, I'm totally stumped on this one,
except to fall back use gcc-4.0)
No tellin' what else will be going wrong after this one gets
fixed.  ;)

Sorry this got long, I wanted to explain best I can.
Thanks for any help.