On Jul 25, 2011, at 3:24 PM, mikel evins wrote:
The Gambit REPL changes have now been committed to the repo.
Note that the new build-gambit-iOS script makes a single copy of the Gambit sources. It compiles it 3 times (i386 for the simulator, and armv6 and armv7 for the real devices), and combines the libraries using "lipo".
I just got around to pulling the latest changes and trying them. They don't appear to work with the latest (Lion) version of the Apple dev tools. Whether trying a configure and make on the root (to build the Max OS X version of Gambit) or cding into examples/iOS and running the build-gambit-iOS script, the build fails with a complaint about a version mismatch between gambit.h and the C sources produces by the gambit compiler.
--me
Afficher les réponses par date
On 2011-07-29, at 2:30 AM, mikel evins wrote:
On Jul 25, 2011, at 3:24 PM, mikel evins wrote:
The Gambit REPL changes have now been committed to the repo.
Note that the new build-gambit-iOS script makes a single copy of the Gambit sources. It compiles it 3 times (i386 for the simulator, and armv6 and armv7 for the real devices), and combines the libraries using "lipo".
I just got around to pulling the latest changes and trying them. They don't appear to work with the latest (Lion) version of the Apple dev tools. Whether trying a configure and make on the root (to build the Max OS X version of Gambit) or cding into examples/iOS and running the build-gambit-iOS script, the build fails with a complaint about a version mismatch between gambit.h and the C sources produces by the gambit compiler.
--me
Which version of Gambit did you have before pulling the latest changes? My guess is that you didn't use "make upgrade".
Marc
On Jul 29, 2011, at 8:36 AM, Marc Feeley wrote:
On 2011-07-29, at 2:30 AM, mikel evins wrote:
On Jul 25, 2011, at 3:24 PM, mikel evins wrote:
The Gambit REPL changes have now been committed to the repo.
Note that the new build-gambit-iOS script makes a single copy of the Gambit sources. It compiles it 3 times (i386 for the simulator, and armv6 and armv7 for the real devices), and combines the libraries using "lipo".
I just got around to pulling the latest changes and trying them. They don't appear to work with the latest (Lion) version of the Apple dev tools. Whether trying a configure and make on the root (to build the Max OS X version of Gambit) or cding into examples/iOS and running the build-gambit-iOS script, the build fails with a complaint about a version mismatch between gambit.h and the C sources produces by the gambit compiler.
--me
Which version of Gambit did you have before pulling the latest changes?
None; I had a bazillion various copies of Gambit from building Delectus and other projects and from experimenting with build strategies, so, for safety's sake, I nuked all of them, hoping to rebuild for all uses from a common set of sources.
Unfortunately, since I did that, I haven't yet found any set of sources I can get through configure, make, make check without errors.
My guess is that you didn't use "make upgrade".
That's true. The instructions I have filed away say to do:
1. ./configure --enable-single-host 2. make -j 2 3. make update
Currently, I run into errors in stage (2), so I never reach stage (3).
--me
A little more info about my failing attempts to build Gambit.
I tried a few variations (devel and non-devel) on downloading and configuring and updating; all failed to make it through a make check without a crash.
I can install the prebuilt Gambit 4.6.1 binaries, and in some quick, superficial testing, they appear to work correctly, but I can't build certain projects (including iOS projects), because I don't have the associated Gambit sources.
I'm using Lion (version 10.7) on an early 2008 24-inch iMac, with the developer tools provided through the App Store (XCode version 4.1, build 4B110).
Has anyone built Gambit using this build environment or something close to it? At this point, I'm sort of wondering whether I need to wipe the machine and do a clean reinstall of everything.
In case anyone wants more details, there's a lot more below:
If I download
http://www.iro.umontreal.ca/~gambit/download/gambit/v4.6/source/gambc-v4_6_1...
then unpack it, run configure --enable-single-host, and do a make, it builds, but if I then attempt a make check, gsi crashes. It prints the following messages in the Terminal window:
making all in include major=`echo v4.6.1 | sed -e "s/v//g" -e "s/.[^.]*.[^.]*//g"`; \ minor=`echo v4.6.1 | sed -e "s/v[^.]*.//g" -e "s/.[^.]*//g"`; \ revision=`echo v4.6.1 | sed -e "s/v[^.]*.[^.]*.//g" -e "s///g"`; \ version_num=`eval expr "( 100000 \* $major ) + ( 1000 \* $minor ) + $revision"`; \ echo "#error "The version indicated in ___VERSION is not supported by gambit.h"" > gambit-not$version_num.h; \ echo "#error "You are probably compiling C code generated by a Gambit compiler earlier or later than v4.6.1"" >> gambit-not$version_num.h; \ echo "#error "___VERSION will be set to $version_num to reduce other errors"" >> gambit-not$version_num.h; \ echo "#undef ___VERSION" >> gambit-not$version_num.h; \ echo "#define ___VERSION $version_num" >> gambit-not$version_num.h; \ echo "#include "gambit.h"" >> gambit-not$version_num.h making all in lib making all in gsi making all in gsc making all in bin making all in misc making all in doc making all in tests making all in examples making all in distr-comp making all in pi making all in ring making all in web-repl making all in web-server making all in tcltk making all in Xlib-simple making all in pthread making all in misc making all in iOS making all in prebuilt making all in macosx making all in windows test -f "gsc-comp" || cp gsc/gsc gsc-comp cd tests && make prefix=/usr/local/Gambit-C exec_prefix=/usr/local/Gambit-C includedir=/usr/local/Gambit-C/include libdir=/usr/local/Gambit-C/lib bindir=/usr/local/Gambit-C/bin docdir=/usr/local/Gambit-C/doc infodir=/usr/local/Gambit-C/info emacsdir=/usr/local/Gambit-C/share/emacs/site-lisp check ------------ TEST 1 (debugging support) ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out /bin/sh: line 1: 93373 Segmentation fault: 11 ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out make[1]: *** [test1] Error 139 make: *** [check] Error 2
I tried a quick make clean followed by make update; I got:
cairagor:gambc-v4_6_1-devel mikel$ make update From http://www.iro.umontreal.ca/~gambit/repo/gambit 431c27a..53a9aa9 master -> origin/master Updating f91139f..53a9aa9 error: The following untracked working tree files would be overwritten by merge: examples/iOS/Prefix.pch Please move or remove them before you can merge. Aborting
Okay; how about we try starting over; I'll try unpacking, configuring, then doing make update (make update and then configure doesn't work, because there is no target for update at that point).
Whoops! Same result as before:
cairagor:gambc-v4_6_1-devel mikel$ make update From http://www.iro.umontreal.ca/~gambit/repo/gambit 431c27a..53a9aa9 master -> origin/master Updating f91139f..53a9aa9 error: The following untracked working tree files would be overwritten by merge: examples/iOS/Prefix.pch Please move or remove them before you can merge. Aborting
Okay, how about we unpack, configure, remove the offending pch file, and then try make update?
No dice. Here's the tail end:
CONFIG_FILES=makefile CONFIG_HEADERS= ./config.status config.status: creating makefile making all in include cd .. && CONFIG_FILES=include/makefile CONFIG_HEADERS= ./config.status config.status: creating include/makefile cd .. && CONFIG_FILES=include/gambit.h CONFIG_HEADERS= ./config.status config.status: creating include/gambit.h major=`echo v4.6.1 | sed -e "s/v//g" -e "s/.[^.]*.[^.]*//g"`; \ minor=`echo v4.6.1 | sed -e "s/v[^.]*.//g" -e "s/.[^.]*//g"`; \ revision=`echo v4.6.1 | sed -e "s/v[^.]*.[^.]*.//g" -e "s///g"`; \ version_num=`eval expr "( 100000 \* $major ) + ( 1000 \* $minor ) + $revision"`; \ echo "#error "The version indicated in ___VERSION is not supported by gambit.h"" > gambit-not$version_num.h; \ echo "#error "You are probably compiling C code generated by a Gambit compiler earlier or later than v4.6.1"" >> gambit-not$version_num.h; \ echo "#error "___VERSION will be set to $version_num to reduce other errors"" >> gambit-not$version_num.h; \ echo "#undef ___VERSION" >> gambit-not$version_num.h; \ echo "#define ___VERSION $version_num" >> gambit-not$version_num.h; \ echo "#include "gambit.h"" >> gambit-not$version_num.h making all in lib cd .. && CONFIG_FILES=lib/makefile CONFIG_HEADERS= ./config.status config.status: creating lib/makefile ../gsc-comp -:~~bin=../bin,~~lib=../lib,~~include=../include -f -c -check _io.scm /bin/sh: ../gsc-comp: No such file or directory make[2]: *** [_io.c] Error 127 make[1]: *** [all-recursive] Error 1 make: *** [update] Error 2
Okay; how about I use gambc-v4_6_1.tgz (not the devel sources)? I download, untar, do configure --enable-single-host and make…
As before; the build worked, but gsi crashed in make check. The message in the Terminal was:
making all in include major=`echo v4.6.1 | sed -e "s/v//g" -e "s/.[^.]*.[^.]*//g"`; \ minor=`echo v4.6.1 | sed -e "s/v[^.]*.//g" -e "s/.[^.]*//g"`; \ revision=`echo v4.6.1 | sed -e "s/v[^.]*.[^.]*.//g" -e "s///g"`; \ version_num=`eval expr "( 100000 \* $major ) + ( 1000 \* $minor ) + $revision"`; \ echo "#error "The version indicated in ___VERSION is not supported by gambit.h"" > gambit-not$version_num.h; \ echo "#error "You are probably compiling C code generated by a Gambit compiler earlier or later than v4.6.1"" >> gambit-not$version_num.h; \ echo "#error "___VERSION will be set to $version_num to reduce other errors"" >> gambit-not$version_num.h; \ echo "#undef ___VERSION" >> gambit-not$version_num.h; \ echo "#define ___VERSION $version_num" >> gambit-not$version_num.h; \ echo "#include "gambit.h"" >> gambit-not$version_num.h making all in lib making all in gsi making all in gsc making all in bin making all in misc making all in doc making all in tests making all in examples making all in distr-comp making all in pi making all in ring making all in web-repl making all in web-server making all in tcltk making all in Xlib-simple making all in pthread making all in misc making all in iOS making all in prebuilt making all in macosx making all in windows test -f "gsc-comp" || cp gsc/gsc gsc-comp cd tests && make prefix=/usr/local/Gambit-C exec_prefix=/usr/local/Gambit-C includedir=/usr/local/Gambit-C/include libdir=/usr/local/Gambit-C/lib bindir=/usr/local/Gambit-C/bin docdir=/usr/local/Gambit-C/doc infodir=/usr/local/Gambit-C/info emacsdir=/usr/local/Gambit-C/share/emacs/site-lisp check ------------ TEST 1 (debugging support) ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out /bin/sh: line 1: 12569 Segmentation fault: 11 ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out make[1]: *** [test1] Error 139 make: *** [check] Error 2
The crash log says:
Process: gsi [12569] Path: /Users/USER/*/gsi Identifier: gsi Version: ??? (???) Code Type: X86-64 (Native) Parent Process: sh [12568]
Date/Time: 2011-07-31 00:45:24.604 -0500 OS Version: Mac OS X 10.7 (11A511) Report Version: 9
Interval Since Last Report: 704720 sec Crashes Since Last Report: 5 Per-App Crashes Since Last Report: 4 Anonymous UUID: 64C04072-CF8C-41B5-852A-4FCB2282064E
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000001
VM Regions Near 0x1: --> __TEXT 0000000108f70000-00000001091dc000 [ 2480K] r-x/rwx SM=COW /Users/USER/*
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x0000000000000001 0 + 1
Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000109253ca1 rbx: 0x00000001092c0c41 rcx: 0x000000010967ff48 rdx: 0x0000000109600428 rdi: 0x00000001093b2ea0 rsi: 0x0000000109253ca1 rbp: 0x00000001092c2f61 rsp: 0x00007fff68b6e708 r8: 0xfffffffffffffffe r9: 0x0000000000000010 r10: 0x0000000000000028 r11: 0x00000001092c2f61 r12: 0x0000000000000010 r13: 0x0000000000000010 r14: 0x00000001092c84c1 r15: 0x00000001092c0de1 rip: 0x0000000000000001 rfl: 0x0000000000010203 cr2: 0x0000000000000001 Logical CPU: 1
Binary Images: 0x108f70000 - 0x1091dbff7 +gsi (??? - ???) <B1D46EDE-BF92-3DB2-9314-0402FCB2A525> /Users/USER/*/gsi 0x7fff68b70000 - 0x7fff68ba4ac7 dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld 0x7fff8a3d1000 - 0x7fff8a413ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib 0x7fff8ba34000 - 0x7fff8ba3afff libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib 0x7fff8d757000 - 0x7fff8d758fff libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib 0x7fff8e935000 - 0x7fff8e936fff libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib 0x7fff8e95d000 - 0x7fff8e95efff libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib 0x7fff8ea66000 - 0x7fff8ea86fff libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib 0x7fff8ec55000 - 0x7fff8ec5aff7 libsystem_network.dylib (??? - ???) <4ABCEEF3-A3F9-3E06-9682-CE00F17138B7> /usr/lib/system/libsystem_network.dylib 0x7fff8ec90000 - 0x7fff8ec91ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib 0x7fff8fe9a000 - 0x7fff8fe9afff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib 0x7fff90022000 - 0x7fff9004ffe7 libSystem.B.dylib (159.0.0 - compatibility 1.0.0) <7B4D685D-939C-3ABE-8780-77A1889E0DE9> /usr/lib/libSystem.B.dylib 0x7fff90050000 - 0x7fff90056ff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib 0x7fff9019f000 - 0x7fff901a4fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib 0x7fff912a2000 - 0x7fff912abfff libnotify.dylib (80.0.0 - compatibility 1.0.0) <BD08553D-8088-38A8-8007-CF5C0B8F0404> /usr/lib/system/libnotify.dylib 0x7fff914a1000 - 0x7fff914affff libdispatch.dylib (187.5.0 - compatibility 1.0.0) <698F8EFB-7075-3111-94E3-891156C88172> /usr/lib/system/libdispatch.dylib 0x7fff9202c000 - 0x7fff92068fff libsystem_info.dylib (??? - ???) <BC49C624-1DAB-3A37-890F-6EFD46538424> /usr/lib/system/libsystem_info.dylib 0x7fff92b67000 - 0x7fff92b6efff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib 0x7fff92b8e000 - 0x7fff92babff7 libxpc.dylib (77.16.0 - compatibility 1.0.0) <0A4B4775-29A9-30D6-956B-3BE1DBF98090> /usr/lib/system/libxpc.dylib 0x7fff92c29000 - 0x7fff92c31fff libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib 0x7fff92e6f000 - 0x7fff92e73fff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib 0x7fff9301a000 - 0x7fff930f7fef libsystem_c.dylib (763.11.0 - compatibility 1.0.0) <1D61CA57-3C6D-30F7-89CB-CC6F0787B1DC> /usr/lib/system/libsystem_c.dylib 0x7fff9312d000 - 0x7fff9312ffff libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib 0x7fff93158000 - 0x7fff9315dfff libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib 0x7fff94486000 - 0x7fff94487ff7 libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib 0x7fff94f18000 - 0x7fff94f22ff7 liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib 0x7fff952f9000 - 0x7fff952fdfff libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib
External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 9892 thread_create: 0 thread_set_state: 78
VM Region Summary: ReadOnly portion of Libraries: Total=52.8M resident=18.1M(34%) swapped_out_or_unallocated=34.6M(66%) Writable regions: Total=74.4M written=116K(0%) resident=172K(0%) swapped_out=0K(0%) unallocated=74.3M(100%)
REGION TYPE VIRTUAL =========== ======= MALLOC 10.2M MALLOC guard page 16K STACK GUARD 4K Stack 64.0M __DATA 2372K __LINKEDIT 47.9M __TEXT 4964K shared memory 12K =========== ======= TOTAL 129.3M
Model: iMac8,1, BootROM IM81.00C1.B00, 2 processors, Intel Core 2 Duo, 2.8 GHz, 4 GB, SMC 1.30f1 Graphics: ATI Radeon HD 2600 Pro, ATI Radeon HD 2600 Pro, PCIe, 256 MB Memory Module: BANK 0/DIMM0, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F7F7F7F7F9B0000, 0x000000000000000000000000000000000000 Memory Module: BANK 1/DIMM1, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F7F7F7F7F9B0000, 0x4C49464554494D454D454D4F52592E434F4D AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8C), Broadcom BCM43xx 1.0 (5.10.131.36.11) Bluetooth: Version 2.5.0f17, 2 service, 19 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: Hitachi HDP725032GLA380, 320.07 GB Parallel ATA Device: OPTIARC DVD RW AD-5630A USB Device: hub_device, apple_vendor_id, 0x911c, 0xfa400000 / 3 USB Device: CanoScan, 0x04a9 (Canon Inc.), 0x2220, 0xfa430000 / 6 USB Device: CTE-650, 0x056a (WACOM Co., Ltd.), 0x0018, 0xfa410000 / 5 USB Device: Apple Cinema HD Display, apple_vendor_id, 0x921c, 0xfa420000 / 4 USB Device: iPhone, apple_vendor_id, 0x1294, 0xfa200000 / 2 USB Device: Built-in iSight, apple_vendor_id, 0x8502, 0xfd400000 / 3 USB Device: Keyboard Hub, apple_vendor_id, 0x1006, 0xfd100000 / 2 USB Device: Razer 1600dpi Mouse, 0x1532, 0x0001, 0xfd110000 / 5 USB Device: Apple Keyboard, apple_vendor_id, 0x0220, 0xfd120000 / 4 USB Device: BRCM2046 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x1a100000 / 2 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x820f, 0x1a110000 / 5 USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x5d100000 / 2 FireWire Device: d2 quadra (button), LaCie, 800mbit_speed FireWire Device: unknown_device, unknown_speed
On 2011-07-31, at 1:59 AM, mikel evins wrote:
A little more info about my failing attempts to build Gambit.
I tried a few variations (devel and non-devel) on downloading and configuring and updating; all failed to make it through a make check without a crash.
I can install the prebuilt Gambit 4.6.1 binaries, and in some quick, superficial testing, they appear to work correctly, but I can't build certain projects (including iOS projects), because I don't have the associated Gambit sources.
I'm using Lion (version 10.7) on an early 2008 24-inch iMac, with the developer tools provided through the App Store (XCode version 4.1, build 4B110).
Has anyone built Gambit using this build environment or something close to it? At this point, I'm sort of wondering whether I need to wipe the machine and do a clean reinstall of everything.
In case anyone wants more details, there's a lot more below:
I have encountered this problem also (with Lion and the new Xcode). The problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1" before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Marc
As annoying as a buggy C compiler is, it's still good news that a workaround exists. Thanks very much!
--me
Sent from my iPad
On Jul 31, 2011, at 6:50 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2011-07-31, at 1:59 AM, mikel evins wrote:
A little more info about my failing attempts to build Gambit.
I tried a few variations (devel and non-devel) on downloading and configuring and updating; all failed to make it through a make check without a crash.
I can install the prebuilt Gambit 4.6.1 binaries, and in some quick, superficial testing, they appear to work correctly, but I can't build certain projects (including iOS projects), because I don't have the associated Gambit sources.
I'm using Lion (version 10.7) on an early 2008 24-inch iMac, with the developer tools provided through the App Store (XCode version 4.1, build 4B110).
Has anyone built Gambit using this build environment or something close to it? At this point, I'm sort of wondering whether I need to wipe the machine and do a clean reinstall of everything.
In case anyone wants more details, there's a lot more below:
I have encountered this problem also (with Lion and the new Xcode). The problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1" before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Marc
On Jul 31, 2011, at 6:50 AM, Marc Feeley wrote:
I have encountered this problem also (with Lion and the new Xcode). The problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1" before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Using the above workaround, I certainly get farther than before. I can make it through the make check without crashes or errors.
After that, I tried this:
1. rm examples/iOS/Prefix.pch (needed because otherwise make update fails when git is unable to update that file)
2. make update
3. cd examples/iOS
4. make examples
5. ./build-gambit-iOS
A cursory examination seems to show that these steps all succeeded, but I'm unable to run Gambit-REPL in the iPad or iPhone simulator. It launches and immediately crashes, complaining that it can't access memory address 1.
Perhaps I need to alter the Makefiles used in the iOS build to ensure that LLVM is not used? Or perhaps I overlooked some other step?
--me
On 2011-07-31, at 4:48 PM, mikel evins wrote:
On Jul 31, 2011, at 6:50 AM, Marc Feeley wrote:
I have encountered this problem also (with Lion and the new Xcode). The problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1" before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Using the above workaround, I certainly get farther than before. I can make it through the make check without crashes or errors.
After that, I tried this:
rm examples/iOS/Prefix.pch (needed because otherwise make update fails when git is unable to update that file)
make update
cd examples/iOS
make examples
./build-gambit-iOS
A cursory examination seems to show that these steps all succeeded, but I'm unable to run Gambit-REPL in the iPad or iPhone simulator. It launches and immediately crashes, complaining that it can't access memory address 1.
Perhaps I need to alter the Makefiles used in the iOS build to ensure that LLVM is not used? Or perhaps I overlooked some other step?
Indeed the build-gambit-iOS script also has to be modified to avoid LLVM gcc. That can be achieved by changing the lines:
case "$kind$platform_type" in
iPhoneOS) config_options_extras=--host=arm-apple-darwin ;;
iPhoneSimulator) config_options_extras= ;;
esac
export CC="$ios_platform_dir/Developer/usr/bin/gcc -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/g++ -isysroot $ios_sdk_dir -arch $arch"
to
case "$kind$platform_type" in
iPhoneOS) config_options_extras=--host=arm-apple-darwin export CC="$ios_platform_dir/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/arm-apple-darwin10-g++-4.2.1 -isysroot $ios_sdk_dir -arch $arch" ;;
iPhoneSimulator) config_options_extras= export CC="$ios_platform_dir/Developer/usr/bin/i686-apple-darwin11-gcc-4.2.1 -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/i686-apple-darwin11-g++-4.2.1 -isysroot $ios_sdk_dir -arch $arch" ;;
esac
I wonder why Apple is moving to LLVM gcc. I've read somewhere that Apple thinks gcc is more buggy than LLVM gcc, and that it generates better code. At least for compiling Gambit, this seems to be a mistaken belief on both counts.
Marc
On Jul 31, 2011, at 5:14 PM, Marc Feeley wrote:
[…further instructions gratefully received…]
Thanks, Marc; I'll give it a go.
I wonder why Apple is moving to LLVM gcc. I've read somewhere that Apple thinks gcc is more buggy than LLVM gcc, and that it generates better code. At least for compiling Gambit, this seems to be a mistaken belief on both counts.
Apple has spent a bunch of labor and money on LLVM. They and some of their third-party developers say that LLVM generally compiles faster than GCC and is better able to provide more helpful and revealing error messages. At least some people are also claiming improvements in generated code for at least some scenarios (Apple is not the only batch of people making this claim; the guys working on the GHC LLVM back end also say that in at least some scenarios they get better-performing code generated by LLVM).
Of course, even if I've remembered all this stuff accurately, and even if it's all true, that doesn't mean LLVM is bug-free. The Gambit sources could still tickle LLVM bugs that others are not seeing--or could interact in some other unfortunate way with the back end. There are a lot of code paths through anything that can compile C, C++, and Objective-C :-).
Thanks again for the help; if you don't hear from me again right away, that's probably a good sign.
:-)
--me
I'm now using 'Apple LLVM compiler 3.0" to compile Gambit (osx, iOS Simulator and iOS device). I've switched to clang as my main compiler now since Apple seems to be making that their main compiler. I use my own set of compile scripts to compile Gambit (from latest git) into a static lib that I then link into my XCode project. I keep 3 separate builds, one for each 'platform' (osx, ios sim and ios device), each in their own directory with separate setup and config scripts. I generally only rebuild the libs when the Gambit repo is updated. Each script is a little different, but to compile the static Gambit lib an iOS arm device (arm7 only), I use the following 2 scripts:
setup.sh (to setup the env):
export PATH="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH" export CC="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk" export CXX="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang++ -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk"
compile.sh:
CFLAGS="-arch armv7" LDFLAGS="-arch armv7" ./configure --host=arm --prefix=/usr/local/Gambit-C/iPhoneOS CFLAGS="-arch armv7" LDFLAGS="-arch armv7" make sudo make install
The script for each type of build is slightly different and is based on getting Gambit to build over the last year or so - and originally based on JLongster's scripts. This is using the latest beta Xcode 4.2 with iOS 5.0 under Lion and SL - but it was working under XCode 4.0 with just changing the CC/CXX paths in setup.sh.
Adam
On Sun, Jul 31, 2011 at 6:14 PM, Marc Feeley feeley@iro.umontreal.cawrote:
On 2011-07-31, at 4:48 PM, mikel evins wrote:
On Jul 31, 2011, at 6:50 AM, Marc Feeley wrote:
I have encountered this problem also (with Lion and the new Xcode). The
problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1"
before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Using the above workaround, I certainly get farther than before. I can
make it through the make check without crashes or errors.
After that, I tried this:
- rm examples/iOS/Prefix.pch (needed because otherwise make update fails
when git is unable to update that file)
make update
cd examples/iOS
make examples
./build-gambit-iOS
A cursory examination seems to show that these steps all succeeded, but
I'm unable to run Gambit-REPL in the iPad or iPhone simulator. It launches and immediately crashes, complaining that it can't access memory address 1.
Perhaps I need to alter the Makefiles used in the iOS build to ensure
that LLVM is not used? Or perhaps I overlooked some other step?
Indeed the build-gambit-iOS script also has to be modified to avoid LLVM gcc. That can be achieved by changing the lines:
case "$kind$platform_type" in
iPhoneOS) config_options_extras=--host=arm-apple-darwin ;;iPhoneSimulator) config_options_extras= ;;
esac
export CC="$ios_platform_dir/Developer/usr/bin/gcc -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/g++ -isysroot $ios_sdk_dir -arch $arch"
to
case "$kind$platform_type" in
iPhoneOS) config_options_extras=--host=arm-apple-darwin exportCC="$ios_platform_dir/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/arm-apple-darwin10-g++-4.2.1 -isysroot $ios_sdk_dir -arch $arch" ;;
iPhoneSimulator) config_options_extras= export CC="$ios_platform_dir/Developer/usr/bin/i686-apple-darwin11-gcc-4.2.1 -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/i686-apple-darwin11-g++-4.2.1 -isysroot $ios_sdk_dir -arch $arch" ;;
esac
I wonder why Apple is moving to LLVM gcc. I've read somewhere that Apple thinks gcc is more buggy than LLVM gcc, and that it generates better code. At least for compiling Gambit, this seems to be a mistaken belief on both counts.
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
BTW, to get Gambit to compile as an iOS library using this script, you need to make a small tweak to Xcode after some Xcode updates (or fresh install). You'll get a link error to crt1.10.6 unless you make the following change in /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib (or any earlier version of the SDK):
sudo ln -s crt1.3.1.o crt1.10.6.o
Then it all compiles fine. You don't need this change for the sim or osx as both already have that lib available. Cheers,
Adam
On Sun, Jul 31, 2011 at 7:58 PM, Adam King akingcoder@gmail.com wrote:
I'm now using 'Apple LLVM compiler 3.0" to compile Gambit (osx, iOS Simulator and iOS device). I've switched to clang as my main compiler now since Apple seems to be making that their main compiler. I use my own set of compile scripts to compile Gambit (from latest git) into a static lib that I then link into my XCode project. I keep 3 separate builds, one for each 'platform' (osx, ios sim and ios device), each in their own directory with separate setup and config scripts. I generally only rebuild the libs when the Gambit repo is updated. Each script is a little different, but to compile the static Gambit lib an iOS arm device (arm7 only), I use the following 2 scripts:
setup.sh (to setup the env):
export PATH="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH" export CC="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk" export CXX="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang++ -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk"
compile.sh:
CFLAGS="-arch armv7" LDFLAGS="-arch armv7" ./configure --host=arm --prefix=/usr/local/Gambit-C/iPhoneOS CFLAGS="-arch armv7" LDFLAGS="-arch armv7" make sudo make install
The script for each type of build is slightly different and is based on getting Gambit to build over the last year or so - and originally based on JLongster's scripts. This is using the latest beta Xcode 4.2 with iOS 5.0 under Lion and SL - but it was working under XCode 4.0 with just changing the CC/CXX paths in setup.sh.
Adam
On Sun, Jul 31, 2011 at 6:14 PM, Marc Feeley feeley@iro.umontreal.cawrote:
On 2011-07-31, at 4:48 PM, mikel evins wrote:
On Jul 31, 2011, at 6:50 AM, Marc Feeley wrote:
I have encountered this problem also (with Lion and the new Xcode).
The problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1"
before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Using the above workaround, I certainly get farther than before. I can
make it through the make check without crashes or errors.
After that, I tried this:
- rm examples/iOS/Prefix.pch (needed because otherwise make update
fails when git is unable to update that file)
make update
cd examples/iOS
make examples
./build-gambit-iOS
A cursory examination seems to show that these steps all succeeded, but
I'm unable to run Gambit-REPL in the iPad or iPhone simulator. It launches and immediately crashes, complaining that it can't access memory address 1.
Perhaps I need to alter the Makefiles used in the iOS build to ensure
that LLVM is not used? Or perhaps I overlooked some other step?
Indeed the build-gambit-iOS script also has to be modified to avoid LLVM gcc. That can be achieved by changing the lines:
case "$kind$platform_type" in
iPhoneOS) config_options_extras=--host=arm-apple-darwin ;;iPhoneSimulator) config_options_extras= ;;
esac
export CC="$ios_platform_dir/Developer/usr/bin/gcc -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/g++ -isysroot $ios_sdk_dir -arch $arch"
to
case "$kind$platform_type" in
iPhoneOS) config_options_extras=--host=arm-apple-darwin exportCC="$ios_platform_dir/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/arm-apple-darwin10-g++-4.2.1 -isysroot $ios_sdk_dir -arch $arch" ;;
iPhoneSimulator) config_options_extras= export CC="$ios_platform_dir/Developer/usr/bin/i686-apple-darwin11-gcc-4.2.1 -isysroot $ios_sdk_dir -arch $arch" export CXX="$ios_platform_dir/Developer/usr/bin/i686-apple-darwin11-g++-4.2.1 -isysroot $ios_sdk_dir -arch $arch" ;;
esac
I wonder why Apple is moving to LLVM gcc. I've read somewhere that Apple thinks gcc is more buggy than LLVM gcc, and that it generates better code. At least for compiling Gambit, this seems to be a mistaken belief on both counts.
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Jul 31, 2011, at 7:58 PM, Adam King wrote:
The script for each type of build is slightly different and is based on getting Gambit to build over the last year or so - and originally based on JLongster's scripts.
Adam, maybe you could email your scripts to Marc and he could incorporate them into the the gambit releases since you seem to be having more consistent success at getting it to build for all platforms under Xcode.
warmest regards,
Ralph
Raffael Cavallaro raffaelcavallaro@me.com
On Sun, Jul 31, 2011 at 8:42 PM, Raffael Cavallaro <raffaelcavallaro@mac.com
wrote:
Adam, maybe you could email your scripts to Marc and he could incorporate them into the the gambit releases since you seem to be having more consistent success at getting it to build for all platforms under Xcode.
I've copied each script below. It actually doesn't need to be two scripts for each platform afterall - I've just updated them (and rebuilt all) with the scripts below under the latest beta of Xcode 4.2 and ran each with my code without issue. However, my setup is probably unique to me but may be of use. I place the primary OSX build under /usr/local/Gambit-C and then the two iOS builds are installed under /usr/local/Gambit-C/iPhoneOS and /usr/local/Gambit-C/iPhoneSimulator - and I've setup Xcode to pick the correct -lgambc to link based on the current target. The 3 scripts are:
OSX:
export CC='clang' export CXX='clang++'
./configure --prefix=/usr/local/Gambit-C CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure --prefix=/usr/local/Gambit-C --enable-single-host --host=i386 make sudo make install
iPhoneSimulator:
export CC='/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk' export CXX='/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang++ -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk'
CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure --prefix=/usr/local/Gambit-C/iPhoneSimulator --host=i386 CFLAGS="-arch i386" LDFLAGS="-arch i386" make sudo make install
iPhoneOS:
export PATH="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH" export CC="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk" export CXX="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang++ -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk"
CFLAGS="-arch armv7" LDFLAGS="-arch armv7" ./configure --host=arm --prefix=/usr/local/Gambit-C/iPhoneOS CFLAGS="-arch armv7" LDFLAGS="-arch armv7" make sudo make install
Note: I have compiled both iPhoneOS and iPhoneSim with '--enable-single-host' in the past, but as it takes a couple of _hours_ to compile with that option, I don't both for those two. But I do for the osx as that's what I use for compiling the scm source to C that get's compiled/linked in the iOS builds. Hope this helps!
Adam
On Sun, Jul 31, 2011 at 9:29 PM, mikel evins mevins@me.com wrote:
On Jul 31, 2011, at 8:26 PM, Adam King wrote:
I've setup Xcode to pick the correct -lgambc to link based on the
current target
What settings do you use to accomplish this bit?
See the attached snapshot of my XCode's 'Build Settings'. If you move your cursor over the 'Debug' or 'Release' lines, a little '+' symbol appers that you can click and then add custom paths depending upon current build target architecture. I only have '-lgambc' specified in 'Other Linker Flags' - so it grabs the correct gambc.a based on the path for the current arch. Cheers,
Adam
On Jul 31, 2011, at 8:42 PM, Adam King wrote:
On Sun, Jul 31, 2011 at 9:29 PM, mikel evins mevins@me.com wrote:
On Jul 31, 2011, at 8:26 PM, Adam King wrote:
I've setup Xcode to pick the correct -lgambc to link based on the current target
What settings do you use to accomplish this bit?
See the attached snapshot of my XCode's 'Build Settings'.
Many thanks.
--me
On Jul 31, 2011, at 8:26 PM, Adam King wrote:
On Sun, Jul 31, 2011 at 8:42 PM, Raffael Cavallaro raffaelcavallaro@mac.com wrote:
Adam, maybe you could email your scripts to Marc and he could incorporate them into the the gambit releases since you seem to be having more consistent success at getting it to build for all platforms under Xcode.
I've copied each script below. It actually doesn't need to be two scripts for each platform afterall - I've just updated them (and rebuilt all) with the scripts below under the latest beta of Xcode 4.2 and ran each with my code without issue. However, my setup is probably unique to me but may be of use. I place the primary OSX build under /usr/local/Gambit-C and then the two iOS builds are installed under /usr/local/Gambit-C/iPhoneOS and /usr/local/Gambit-C/iPhoneSimulator - and I've setup Xcode to pick the correct -lgambc to link based on the current target. The 3 scripts are:
OSX:
export CC='clang' export CXX='clang++'
./configure --prefix=/usr/local/Gambit-C CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure --prefix=/usr/local/Gambit-C --enable-single-host --host=i386 make sudo make install
So using the currently-available pre-release version of the dev tools with XCode 4.2 (build 4D139), the 4.6.1 devel sources, and the above commands, the compile of the Gambit sources gets to here:
making all in include major=`echo v4.6.1 | sed -e "s/v//g" -e "s/.[^.]*.[^.]*//g"`; \ minor=`echo v4.6.1 | sed -e "s/v[^.]*.//g" -e "s/.[^.]*//g"`; \ revision=`echo v4.6.1 | sed -e "s/v[^.]*.[^.]*.//g" -e "s///g"`; \ version_num=`eval expr "( 100000 \* $major ) + ( 1000 \* $minor ) + $revision"`; \ echo "#error "The version indicated in ___VERSION is not supported by gambit.h"" > gambit-not$version_num.h; \ echo "#error "You are probably compiling C code generated by a Gambit compiler earlier or later than v4.6.1"" >> gambit-not$version_num.h; \ echo "#error "___VERSION will be set to $version_num to reduce other errors"" >> gambit-not$version_num.h; \ echo "#undef ___VERSION" >> gambit-not$version_num.h; \ echo "#define ___VERSION $version_num" >> gambit-not$version_num.h; \ echo "#include "gambit.h"" >> gambit-not$version_num.h making all in lib clang -arch i386 -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fno-move-loop-invariants -fPIC -fno-common -mieee -mieee-with-inexact -mieee-fp -I"../include" -c -o "_io.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR=""/usr/local/gambit/macosx"" -D___SYS_TYPE_CPU=""i386"" -D___SYS_TYPE_VENDOR=""pc"" -D___SYS_TYPE_OS=""none"" -D___CONFIGURE_COMMAND=""./configure --prefix=/usr/local/gambit/macosx --enable-single-host --host=i386"" -D___OBJ_EXTENSION="".o"" -D___EXE_EXTENSION="""" -D___BAT_EXTENSION="""" -D___PRIMAL _io.c -D___LIBRARY clang: warning: argument unused during compilation: '-fschedule-insns2' clang: warning: argument unused during compilation: '-fno-trapping-math' clang: warning: argument unused during compilation: '-fno-move-loop-invariants' clang: warning: argument unused during compilation: '-mieee' clang: warning: argument unused during compilation: '-mieee-with-inexact' clang: warning: argument unused during compilation: '-mieee-fp'
…and sits there for a few hours.
I'm going to let it sit for a while longer, and then, perhaps tomorrow, try something else.
--me
On Aug 1, 2011, at 12:58 AM, mikel evins wrote:
On Jul 31, 2011, at 8:26 PM, Adam King wrote:
OSX:
export CC='clang' export CXX='clang++'
./configure --prefix=/usr/local/Gambit-C CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure --prefix=/usr/local/Gambit-C --enable-single-host --host=i386 make sudo make install
So using the currently-available pre-release version of the dev tools with XCode 4.2 (build 4D139), the 4.6.1 devel sources, and the above commands, the compile of the Gambit sources gets to here:
[...]
…and sits there for a few hours.
I'm going to let it sit for a while longer, and then, perhaps tomorrow, try something else.
Switching the compiler to "i686-apple-darwin11-gcc-4.2.1" per Marc's earlier suggestion works; it produces a build and install that pass the test suite. (Whew!)
I'll see how things turn out with the iOS builds.
--me
On Mon, Aug 1, 2011 at 1:58 AM, mikel evins mevins@me.com wrote:
... snip ...
D___CONFIGURE_COMMAND=""./configure --prefix=/usr/local/gambit/macosx --enable-single-host --host=i386"" -D___OBJ_EXTENSION="".o"" -D___EXE_EXTENSION="""" -D___BAT_EXTENSION="""" -D___PRIMAL _io.c -D___LIBRARY clang: warning: argument unused during compilation: '-fschedule-insns2' clang: warning: argument unused during compilation: '-fno-trapping-math' clang: warning: argument unused during compilation: '-fno-move-loop-invariants' clang: warning: argument unused during compilation: '-mieee' clang: warning: argument unused during compilation: '-mieee-with-inexact' clang: warning: argument unused during compilation: '-mieee-fp'
…and sits there for a few hours.
It does take a few hours for me when '--enable-single-host' is enabled - and it does use lots of virtual mem. I have 4Gb RAM and a SSD drive for the swap space, and it still took several hours - that's why I didn't bother adding the '--enable-single-host' option for the iOS builds. If you removed that option, you'll probably find it takes only a couple of mins to build with clang. And as you noticed, clang doesn't appear to support several gcc flags.
Adam
On Jul 31, 2011, at 8:26 PM, Adam King wrote:
iPhoneSimulator:
export CC='/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk' export CXX='/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang++ -isysroot /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk'
CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure --prefix=/usr/local/Gambit-C/iPhoneSimulator --host=i386 CFLAGS="-arch i386" LDFLAGS="-arch i386" make sudo make install
iPhoneOS:
export PATH="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH" export CC="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk" export CXX="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang++ -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk"
CFLAGS="-arch armv7" LDFLAGS="-arch armv7" ./configure --host=arm --prefix=/usr/local/Gambit-C/iPhoneOS CFLAGS="-arch armv7" LDFLAGS="-arch armv7" make sudo make install
On my system the simulator build appears to work; the iPhoneOS build does not. Warnings and error messages include:
configure: WARNING: If you wanted to set the --build type, don't use --host.
configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Gambit-C" | #define PACKAGE_TARNAME "gambc-v4_6_1" | #define PACKAGE_VERSION "v4.6.1" | #define PACKAGE_STRING "Gambit-C v4.6.1" | #define PACKAGE_BUGREPORT "gambit@iro.umontreal.ca" | #define PACKAGE_URL "" | /* end confdefs.h. */ | #include <stdio.h> | int | main () | { | FILE *f = fopen ("conftest.out", "w"); | return ferror (f) || fclose (f) != 0; | | ; | return 0; | } configure: error: C compiler cannot create executables
OS5.0.sdk -V >&5 clang: error: argument to '-V' is missing (expected 1 value) clang: error: no input files
ld: library not found for -lcrt1.10.6.o
Okay, got a device build that superficially appears correct, using the following modifications to Adam's flags:
Here's Adam's setup (which failed on my system):
export PATH="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH" export CC="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk" export CXX="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/clang++ -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk"
CFLAGS="-arch armv7" LDFLAGS="-arch armv7" ./configure --host=arm --prefix=/usr/local/Gambit-C/iPhoneOS CFLAGS="-arch armv7" LDFLAGS="-arch armv7" make sudo make install
Here's my modified version (which succeeded on my system):
export PATH="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:$PATH" export CC='/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-gcc-4.2.1 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk'
export CXX='/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-g++-4.2.1 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk'
./configure --host=arm --prefix=/usr/local/Gambit-C/iPhoneOS make sudo make install
(Yes, removing the CFLAGS and LDFLAGS from the .configure and make lines does appear to be necessary).
--me
On Mon, Aug 1, 2011 at 8:04 PM, mikel evins mevins@me.com wrote:
ld: library not found for -lcrt1.10.6.o
See my earlier email about fixing this error (only needed for iOS device builds). I'm about to go on vacation, so unlikely I'll be able to help any further. Good luck getting it all going!
Adam
On Aug 1, 2011, at 7:41 PM, Adam King wrote:
On Mon, Aug 1, 2011 at 8:04 PM, mikel evins mevins@me.com wrote:
ld: library not found for -lcrt1.10.6.o
See my earlier email about fixing this error (only needed for iOS device builds). I'm about to go on vacation, so unlikely I'll be able to help any further. Good luck getting it all going!
And thanks very much for your help!
I seem to have a working build using GCC; if I dislike it, I'll retry with clang and your fix for this error.
Hallo,
On Mon, Aug 1, 2011 at 12:14 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
I wonder why Apple is moving to LLVM gcc. I've read somewhere that Apple thinks gcc is more buggy than LLVM gcc, and that it generates better code. At least for compiling Gambit, this seems to be a mistaken belief on both counts.
Marc
Apple departed from GCC mainly for licensing reasons. As GCC 4.2 is the last version with uses GPLv2, Apple is stuck with that one until Clang can completely replace GCC. BTW, LLVM-GCC is just a hack (a compiler that uses the GCC front-end and LLVM back-end) until Clang is stable enough.
On 2011-07-31, at 7:50 AM, Marc Feeley wrote:
On 2011-07-31, at 1:59 AM, mikel evins wrote:
A little more info about my failing attempts to build Gambit.
I tried a few variations (devel and non-devel) on downloading and configuring and updating; all failed to make it through a make check without a crash.
I can install the prebuilt Gambit 4.6.1 binaries, and in some quick, superficial testing, they appear to work correctly, but I can't build certain projects (including iOS projects), because I don't have the associated Gambit sources.
I'm using Lion (version 10.7) on an early 2008 24-inch iMac, with the developer tools provided through the App Store (XCode version 4.1, build 4B110).
Has anyone built Gambit using this build environment or something close to it? At this point, I'm sort of wondering whether I need to wipe the machine and do a clean reinstall of everything.
In case anyone wants more details, there's a lot more below:
I have encountered this problem also (with Lion and the new Xcode). The problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1" before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Indeed it is LLVM gcc that is buggy. It generates incorrect code for taking the address of a label (for use in computed gotos) when the -O1 option is used. The attached file exhibits the problem in a small C program.
I have just submitted a bug report to the LLVM group. I hate buggy compilers...
Marc
Interesting. Does this extend beyond llvm-gcc to clang or non -O1 flags? Does it happen with DragonEgg ( http://dragonegg.llvm.org/ ) ?
best, Jason
On Mon, Aug 15, 2011 at 2:10 PM, Marc Feeley feeley@iro.umontreal.cawrote:
On 2011-07-31, at 7:50 AM, Marc Feeley wrote:
On 2011-07-31, at 1:59 AM, mikel evins wrote:
A little more info about my failing attempts to build Gambit.
I tried a few variations (devel and non-devel) on downloading and
configuring and updating; all failed to make it through a make check without a crash.
I can install the prebuilt Gambit 4.6.1 binaries, and in some quick,
superficial testing, they appear to work correctly, but I can't build certain projects (including iOS projects), because I don't have the associated Gambit sources.
I'm using Lion (version 10.7) on an early 2008 24-inch iMac, with the
developer tools provided through the App Store (XCode version 4.1, build 4B110).
Has anyone built Gambit using this build environment or something close
to it? At this point, I'm sort of wondering whether I need to wipe the machine and do a clean reinstall of everything.
In case anyone wants more details, there's a lot more below:
I have encountered this problem also (with Lion and the new Xcode). The
problem is due to LLVM gcc which is the default C compiler now and which does not compile the Gambit sources properly when the --enable-single-host configure option is given. I've tried using gdb to find where the error is, but it is giving me an execution trace which doesn't correlate with the sources so I am confused in regards to the location of the error.
So to fix the problem temporarily I did
CC="i686-apple-darwin11-gcc-4.2.1" ./configure --enable-single-host make make check
I also committed a patch to look for "i686-apple-darwin11-gcc-4.2.1"
before "gcc", but that is not a long term solution.
My guess is that LLVM gcc is buggy, but I have not yet found a proof.
Indeed it is LLVM gcc that is buggy. It generates incorrect code for taking the address of a label (for use in computed gotos) when the -O1 option is used. The attached file exhibits the problem in a small C program.
I have just submitted a bug report to the LLVM group. I hate buggy compilers...
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-
Adam King -
Alex Queiroz -
Jason E. Aten -
Marc Feeley -
mikel evins -
Raffael Cavallaro