dyld: lazy symbol binding failed: Symbol not found: _iconv_open

[alce]

Hi,
Snow Leopard 10.6.4
node 0.2.0

node> var iconv = new Iconv('ISO-8859-1', 'UTF-8');
dyld: lazy symbol binding failed: Symbol not found: _iconv_open
Referenced from: /Users/alce/.node_libraries/iconv.node
Expected in: flat namespace

dyld: Symbol not found: _iconv_open
Referenced from: /Users/alce/.node_libraries/iconv.node
Expected in: flat namespace

From what I can gather, there may be something off with libiconv on my machine but can't exactly put my finger on it. Is it possible for you to point me in the right direction?

Thanks,
Juan

[bnoordhuis]

Juan, I don't have a Mac myself so I can't verify it but could your problem be related to OS X's weak linking feature?

http://developer.apple.com/mac/library/technotes/tn2002/tn2064.html

PS: Did you compile node-iconv with node-waf or by hand?

[bnoordhuis]

Okay. According to a well-informed source (friend of mine with a MacBook) this happens when people have multiple versions of libiconv installed. Set DYLD_LIBRARY_PATH to the directory that contains the proper version and all should be well (crosses fingers).

[alce]

I compiled with node-waf. I only had one libiconv (system) but apparently it does not export the symbols the extension is calling.

I built libiconv form source, installed it in another location and set DYLD_LIBRARY_PATH explicitly but that didn't help.

Thanks for your help.

[bnoordhuis]

Could you post the output of `nm -D /path/to/libiconv.so' | grep iconv? And perhaps of your libc as well.

Some googling suggests this might be a bug in certain versions of Apple's gcc. What happens if you build the module with a newer or older gcc?

[bnoordhuis]

Okay, I pushed a possible fix (in two commits, woe be me). Could you update your local clone?

[alce]

OS X's nm does not accept a -D argument but hopefully this is what you are after.

~ $ nm -fj /usr/lib/libiconv.dylib | grep iconv
___iconv_2VersionNumber
___iconv_2VersionString
__libiconv_version
_iconv
_iconv_canonicalize
_iconv_close
_iconv_open
_iconvctl
_iconvlist
_libiconv_relocate
_libiconv_set_relocation_prefix

Is there something specific you want me to look for on this one?
~ $ nm -fj /usr/lib/libc.dylib | wc -l
8391

I pulled your changes and recompiled but no luck yet.

[alce]

Some additional info, this looks odd to me:

~/.node_libraries $ otool -L iconv.node
iconv.node:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

From otools' man page:

DESCRIPTION
The otool command displays specified parts of object files or libraries. Otool
understands both Mach-O (Mach object) files and universal file
formats....so on and so forth...

 -L     Display the names and version numbers of the shared libraries that the 
   object   file uses.

Shouldn't /usr/lib/libiconv.dylib be listed here?

[bnoordhuis]

Possibly. iconv might also be part of your libc (it is with glibc). Could you check that?

[bnoordhuis]

Okay, just tried it on the MacBook of a co-worker and I got the same result ('Symbol not found'). I've an inkling of the cause, I'll try to come up with a patch later today.

[bnoordhuis]

Well, I wrote a patch that let node-waf check for and explicitly link against libiconv but that didn't help. I don't know how to solve this but I'll leave the issue open for when someone comes along who does.

[alce]

Thanks so much for your help.
I am working on other parts of my application right now but I'll need to get back to this eventually. When I do, I'll dig deeper and see if I can find a solution or provide you with more information.

Cheers,
ja

[nestorlafon]

hi, same problem here but in Leopard (10.5.x) and xcode tools 3.1. So it looks it is not only happening on Snow Leopard and the lastest tools.

It'd be good to put a warning in the Readme, I wasted 30 min trying to figure out what was my problem until I clicked on issues.

Some more info, these are all the libraries where I could find the symbol:

mini:node nlafon$ nm -fjo /usr/lib/*.dylib | grep iconv_open
/usr/lib/libaprutil-1.0.2.7.dylib: _iconv_open
/usr/lib/libaprutil-1.0.dylib: _iconv_open
/usr/lib/libaprutil-1.dylib: _iconv_open
/usr/lib/libiconv.2.4.0.dylib: _iconv_open
/usr/lib/libiconv.2.4.0.dylib: _libiconv_open
/usr/lib/libiconv.2.dylib: _iconv_open
/usr/lib/libiconv.2.dylib: _libiconv_open
/usr/lib/libiconv.dylib: _iconv_open
/usr/lib/libiconv.dylib: _libiconv_open
/usr/lib/libmecab.1.0.0.dylib: _iconv_open
/usr/lib/libmecab.1.dylib: _iconv_open
/usr/lib/libmecab.dylib: _iconv_open
/usr/lib/libwx_macud-2.8.0.1.1.dylib: _iconv_open
/usr/lib/libwx_macud-2.8.0.dylib: _iconv_open
/usr/lib/libwx_macud-2.8.dylib: _iconv_open

thanks

[alce]

Nextorlg,

I found a partial fix for this problem. First, compile libiconv from source and install it in an alternate location. I installed it on /usr/local (be sure to leave system's libiconv alone).

Then use this fork http://github.com/alce/node-iconv to compile the extension passing the path where you installed libiconv to the configure command:

node-waf configure --libiconv=/usr/local (or whatever path you installed it to)
node-waf build install

The only thing that changes in my fork is the wscrip file but, as is, the extension does not compile on linux.

[bnoordhuis]

Thanks Juan, I pulled in your patch with some amendments so it compiles on linux. If either one of you can confirm that node-iconv now builds fine on OS X, I'll close the issue.

[nestorlafon]

Gracias Juan.

It seems to work, I haven't had time to test it in the code but at least the missing symbol error is gone. This is, step-by-step, what I did for future reference:

• Download the source code fo libiconv from http://www.gnu.org/software/libiconv/#downloading
• In the terminal:
  
tar -xzvf libiconv-1.13.1.tar.gz
cd libiconv-1.13.1
./configure --prefix=/usr/local
make
sudo make install
cd ..
git clone git://github.com/alce/node-iconv.git
cd node-iconv/
node-waf configure --libiconv=/usr/local
node-waf build install


[alce]

Great nextorlg!

Ben, with the changes you made, the extension still links properly if you provide an alternate libiconv. With the instructions for OSX you have now

node-waf configure build install --libiconv=/usr

it will link against system's libiconv, which is the one that gives trouble. It would probably be a good idea to specify that to install on OSX, users need to compile libiconv from source and then pass the path to node-waf. The path needs to be other than /usr since that's where the system's library is.

[bnoordhuis]

Thanks for the heads-up, Juan. I've updated the README. I'll probably include libiconv as a source tree so node-iconv can link against a known-good version.

[rozzy]

Hey, folks!
Thanks for your help. I have same trouble. I am on Mac OS X Mountain Lion with Xcode 4.5.2. I had a big trouble with libiconv library.

At first i found that trouble when i was working with heroku. git push heroku master outputed:

$ git push heroku master
dyld: lazy symbol binding failed: Symbol not found: _libiconv_open
  Referenced from: /usr/local/bin/git
  Expected in: /usr/lib/libiconv.2.dylib

dyld: Symbol not found: _libiconv_open
  Referenced from: /usr/local/bin/git
  Expected in: /usr/lib/libiconv.2.dylib

And then the same error appeared with brew and git. I searched for solution for several days. I tried a lot of unnecessary things. But in result, i removed git, updated brew and installed git once again. Now it's work perfect.

$ brew uninstall git
$ brew update
$ brew install git

I think, this solution also can be helping.