Re: [Gtk-osx-users] Symbol not found: _iconv on LION
- From: John Ralls <jralls ceridwen us>
- To: GTK+-2 OSX Users <gtk-osx-users lists sourceforge net>
- Subject: Re: [Gtk-osx-users] Symbol not found: _iconv on LION
- Date: Thu, 21 Jul 2011 09:22:41 -0400
On Jul 21, 2011, at 2:26 AM, Richard Procter wrote:
>
> On 21/07/2011, at 3:53 PM, Olivier Sessink wrote:
>
>> Hi all,
>>
>> I've received various reports from users that have upgraded to Lion that
>> Bluefish won't start anymore:
>>
>> Dyld Error Message:
>> Symbol not found: _iconv
>> Referenced from: /usr/lib/libcups.2.dylib
>> Expected in:
>> /Applications/Bluefish.app/Contents/Resources/lib/libiconv.2.dylib
>> in /usr/lib/libcups.2.dylib
>>
>> I don't really understand this message, /usr/lib/libcups.2.dylib
>> references a function in
>> /Applications/Bluefish.app/Contents/Resources/lib/libiconv.2.dylib ??
>
> Not directly, but if the dynamic linker is configured to prefer your bundled libiconv then that is what it will be linked against at runtime. See dyld(1) and DYLD_LIBRARY_PATH.
Unfortunately, not so easy. Once the libiconv in the bundle is loaded, dyld won't load any other ones, so you still get the error from libcups.
Having dl'd the sources for Apple's libiconv, it appears to have diverged substantially from gnu's. I originally included libiconv into the gtk-osx build because of problems with x86_64; that turns out to have been the wrong solution.
I think the solution is to remove libiconv and rebuild everything; the automake macro which (incorrectly) decides that it's gnu-compatible will have to be fixed.
Regards,
John Ralls
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]