Linkage failing on OS/X Lion

[arikfr]

Using both the split-browser branch and the split-browser-lion-merge branch my build fails in the linkage stage.

              --enable-rubyinterp \
              --enable-pythoninterp \
              --enable-perlinterp \
              --enable-cscope

And then:

[...]
link.sh: The file 'auto/link.sed' exists, which is going to be used now.
link.sh: If linking fails, try deleting the auto/link.sed file.
link.sh: If this fails too, try creating an empty auto/link.sed file.
link.sh: Using unmodified link command
  /usr/bin/gcc-4.2   -L. -L/usr/local/lib -L. -L/usr/local/lib      -L/usr/local/lib    -o Vim objects/buffer.o objects/blowfish.o objects/charset.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/fileio.o objects/fold.o objects/getchar.o objects/hardcopy.o objects/hashtab.o  objects/if_cscope.o objects/if_xcmdsrv.o objects/mark.o objects/memline.o objects/menu.o objects/message.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o objects/popupmnu.o objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o objects/sha256.o objects/spell.o objects/syntax.o  objects/tag.o objects/term.o objects/ui.o objects/undo.o objects/version.o objects/window.o objects/gui.o objects/gui_beval.o objects/pty.o objects/gui_macvim.o objects/MMBackend.o objects/MacVim.o   objects/if_perl.o objects/if_perlsfio.o objects/if_python.o   objects/if_ruby.o objects/os_macosx.o objects/os_mac_conv.o  objects/netbeans.o  objects/main.o objects/memfile.o -framework Cocoa -framework Carbon      -lm -lncurses  -liconv -framework Cocoa    -L/opt/local/lib -L/usr/local/lib  -L/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -lperl -ldl -lm -lutil -lc -framework Python   -lruby.1.9.1 -lpthread -ldl -lobjc -L/Users/arikfr/.rvm/rubies/ruby-1.9.2-p180/lib   
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
      _buf_write_bytes in fileio.o
      _readfile in fileio.o
      _my_iconv_open in mbyte.o
      _string_convert_ext in mbyte.o
     (maybe you meant: _my_iconv_open)
  "_iconv_close", referenced from:
      _buf_write in fileio.o
      _readfile in fileio.o
      _my_iconv_open in mbyte.o
      _convert_setup_ext in mbyte.o
  "_iconv_open", referenced from:
      _my_iconv_open in mbyte.o
     (maybe you meant: _my_iconv_open)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [Vim] Error 1

(I tried deleting the auto/link.sed file and also putting an empty one..)

I have the iconv lib on my machine.. Any ideas on what could've go wrong?

[alloy]

It’s probably using an iconv that you’ve installed which has not been built for x86_64. Can you find the iconv being used and check it with file? In my case it’s the system version:

% file /usr/lib/libiconv.dylib
/usr/lib/libiconv.dylib: Mach-O universal binary with 3 architectures
/usr/lib/libiconv.dylib (for architecture x86_64):  Mach-O 64-bit dynamically linked shared library x86_64
/usr/lib/libiconv.dylib (for architecture i386):    Mach-O dynamically linked shared library i386
/usr/lib/libiconv.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc

Alternatively, you can download a build: https://github.com/alloy/macvim/downloads

[arikfr]

I'm not sure which libiconv.dylib it uses, but if it uses the one in /usr/lib then my results are similar to yours:

$ file /usr/lib/libiconv.dylib
/usr/lib/libiconv.dylib: Mach-O universal binary with 2 architectures
/usr/lib/libiconv.dylib (for architecture x86_64):  Mach-O 64-bit dynamically linked shared library x86_64
/usr/lib/libiconv.dylib (for architecture i386):    Mach-O dynamically linked shared library i386```
How can I tell which one it really uses?

For some reason I was under the impression that there are no builds for downloads. Will try it now. Thanks.

[alloy]

In the command it includes these options: -L/opt/local/lib -L/usr/local/lib, that’s where I’m guessing you might find it.

[arikfr]

In both of these paths the libiconv file is compiled for 64bit. Is there a way to make the linkage process more verbose and print out the file it tries to link?

[alloy]

Hmm, sorry, I’m not familiar enough with those compiler options :/ Another thing you can try is to use mdfind to look for potential other installations of the lib, or otherwise grab the latest build from: https://github.com/alloy/macvim/downloads

[arikfr]

All the version that I found via mdfind (except that ones of the iPhone simulator) are 64bit. I'm giving up at this point -- I will just use your build.

Yesterday I had performance issues with the latest build, but the build 250720112118 seems to work fine. I will try to work with it for a day, and if all goes ok I will try the latest again.

Thank you!

[alloy]

What kind of performance issues were you running into? Because the 250720112118 build is really outdated compared to upstream. It might be useful to see if you are experiencing the same performance issues with an upstream build.

[arikfr]

Just to clarify, I had the performance issues with the 020920111108 build. Everything was slow and after I closed MacVim, there were still vim processes running in the background using 60% CPU.

So far the 250720112118 build was running ok, so I will give the 020920111108 build second chance.