At Wed, 7 Sep 2011 21:47:17 -0700, Eric Dobson wrote: > I regularly build racket from HEAD on OS X with no problems, but > tonight I decided to try the 64 bit version and couldn't get it to > compile. The error I got was: > > Undefined symbols for architecture x86_64: > "_iconv_close", referenced from: > _close_converter in libracket.a(string.o) > _scheme_close_converter in libracket.a(string.o) > _do_convert in libracket.a(string.o) > _byte_string_close_converter in libracket.a(string.o) > _string_to_from_locale in libracket.a(string.o) > "_iconv_open", referenced from: > _do_convert in libracket.a(string.o) > _string_to_from_locale in libracket.a(string.o) > _scheme_open_converter in libracket.a(string.o) > "_iconv", referenced from: > _do_convert in libracket.a(string.o) > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make[4]: *** [Racket.framework/Versions/5.1.3.6/Racket] Error 1 > > The command I ran to install it was > > mkdir build && cd build && ../configure --disable-docs --enable-mac64 > && make -j2 && make install -j2 > > Is there something I am missing, or is it just broken currently?
That problem happens when the build attempts to use iconv headers from the system and iconv libraries from MacPorts. Since (it appears) you have libffi from MacPorts, `-L/opt/local/lib' gets added to the link line, while there's no `-I/opt/local/include' during compile --- only the libffi-specific `-I/opt/local/lib/libffi-3.0.9/include', so that creates a mismatch for `-liconv'. The simplest solution is to configure with `--disable-libffi', which causes the build to use its own copy of libffi. I'm not sure whether the `configure' script should be doing something different to avoid the iconv problem automatically. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
