[racket-dev] Build failure on OS X

It looks like it was a problem with libffi, which was also out of date in my macports. I upgraded it before your email, and the build got past that point where it was failing. Hopefully it won't have any more problems. 

Thanks for the help.

-Eric


On Apr 21, 2011, at 10:17 PM, Matthew Flatt wrote:

> The recent change to `configure' makes it use `pkg-config' to add -L
> and -I flags for libffi. But those should flags be added consistently;
> that is, you should end up with a build that uses `libiconv' from
> macports.
> 
> Did you run `configure' in a fresh build directory? If not, maybe you
> have files leftover from a previous build that had different flags from
> `configure'?
> 
> If not, can you show the compile line for "string.c"?
> 
> At Thu, 21 Apr 2011 22:01:31 -0400, Eric Dobson wrote:
>> I don't have any *FLAGS variables set in my environment when I run configure or 
>> make. But I do have libiconv installed through macports. It was out of date, 
>> and I upgraded it, but now I am getting a different message:
>> 
>> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
>> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  -liconv 
>> -L/opt/local/lib -lffi   
>> ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported 
>> file format which is not the architecture being linked (i386)
>> Undefined symbols:
>>  "_iconv_close", referenced from:
>>      _do_convert in libracket.a(string.o)
>>      _do_convert in libracket.a(string.o)
>>      _do_convert in libracket.a(string.o)
>>      _string_to_from_locale in libracket.a(string.o)
>>      _string_to_from_locale in libracket.a(string.o)
>>      _string_to_from_locale in libracket.a(string.o)
>>      _close_converter 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)
>>      _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
>> collect2: ld returned 1 exit status
>> 
>> (Note the warning about a different architecture.)
>> 
>> I assume that If I tell it to use the system version of iconv, things will work 
>> out. But how do I tell it to ignore the bad version?
>> 
>> -Eric
>> 
>> 
>> 
>> On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote:
>> 
>>> It looke like you have `-L/opt/local/lib' in your LDFLAGS
>>> configuration. Do you also have `-I/opt/local/include' in CPPFLAGS?
>>> 
>>> You machine is probably like mine, where you have two installations of
>>> libiconv, and this error happens when the C headers of one installation
>>> get mixed with the lib of the other.
>>> 
>>> At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote:
>>>> I tried to build the git HEAD today and ran into problems. During the make 
>>>> process, it fails to create the framework with the following error message:
>>>> 
>>>> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
>>>> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  
>> -liconv 
>>>> -L/opt/local/lib -lffi   
>>>> Undefined symbols:
>>>> "_iconv_close", referenced from:
>>>>     _do_convert in libracket.a(string.o)
>>>>     _do_convert in libracket.a(string.o)
>>>>     _do_convert in libracket.a(string.o)
>>>>     _string_to_from_locale in libracket.a(string.o)
>>>>     _string_to_from_locale in libracket.a(string.o)
>>>>     _string_to_from_locale in libracket.a(string.o)
>>>>     _close_converter 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)
>>>>     _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
>>>> collect2: ld returned 1 exit status
>>>> 
>>>> Does anyone know what might cause this?
>>>> 
>>>> Thanks,
>>>> Eric
>>>> 
>>>> 
>>>> _________________________________________________
>>>> For list-related administrative tasks:
>>>> http://lists.racket-lang.org/listinfo/dev