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.
