add /usr/local/include to search path

[lamont-granquist]

If iconv is installed in /usr/local/include but there is no pkg-config
information for the package, then extconf will fail to find a path to
the header files and will not be able to provide it to the libxml2
build.

I don't know a better way of solving this problem, since otherwise the
idea is that you want to use the default mkmf CFLAGS and be able to
tell which include directory the default compile is finding the header
files in. We'd need to do something like expand the $CFLAGS (hard enough
with mkmf) and then pop off the -I's and add them back one at a time
until you found where iconv.h was actually hiding.

[lamont-granquist]

This attempts to address #442

[lamont-granquist]

See comments at #442 (comment)

[knu]

I'm not absolutely sure why this is required.

• OS X should have /usr/include/iconv.h available.
• In any case, --with-iconv-dir=/usr/local or --with-iconv-include=/usr/local/include should do what this patch does.

I'd much like to see mkmf.log generated on the failing box pasted somewhere, because nokogiri installs fine on my Macs (OS X 10.9.4).

[lamont-granquist]

not on mine, 10.9.3:

% ls -la /usr/include/iconv.h
ls: /usr/include/iconv.h: No such file or directory

either --with-iconv-dir or --with-system-libraries does work around the problem.

[lamont-granquist]

mkmf.log is pretty dull:

% cat mkmf.log
package configuration for libiconv is not found

[knu]

Missing /usr/include/iconv.h is a sign of your system missing something as a POSIX compliant build environment. With Xcode and its Command Line Tools installed, iconv.h should be there (confirmed with Xcode 5.1 at least). This is one problem.

The second problem of --with-iconv-* not working might be because you (or bundle, gem or any other possible wrapper) specified the option multiple values, in which case idir in the code would look something like "/some/other/dir:/usr/local/include". The code as it is now does not support that, which I'll fix.

[lamont-granquist]

Xcode 5.1.1 is installed. Googling around to try to find if there's any way to uninstall/reinstall

[lamont-granquist]

Tried just dragging Xcode to the trash and the re-downloading and that failed to re-install the iconv.h header file, also tried running xcode-select afterwards.

[lamont-granquist]

Okay, so the problem with the missing header file is fixed by re-install'ing the Command Line Tools for Xcode package

https://developer.apple.com/downloads/

This must be getting trashed on upgrade/downgrade/restore for so many people to be hitting this problem.

But...

'gem install nokogiri' alone is still failing. It gets further, but it can't find iconv_open or libiconv_open in either the header or the library:

/Users/lamont/.rvm/rubies/ruby-2.1.2/bin/ruby extconf.rb
Building nokogiri using packaged libraries.
checking for iconv.h... yes
checking for iconv_open() in iconv.h... no
checking for iconv_open() in -liconv... no
checking for libiconv_open() in iconv.h... no
checking for libiconv_open() in -liconv... no
-----
libiconv is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.

[knu]

@lamont-granquist Great you tracked it down. This info should be added to the tutorial page which looks way too out-of-date.

As for the failure, what compiler/linker errors are there in mkmf.log?

[lamont-granquist]

here you are:

https://gist.github.com/lamont-granquist/4903036716c5216ecbc8

there's a lot of this:

conftest.c:15:29: error: too few arguments to function call, expected 2, have 0

looks kinda like the functions exist, but clang is being strict about argument checking. i'm not sure why it works against the homebrew /usr/local version and doesn't work with the /usr version...

[lamont-granquist]

lol, i think i'm wrong and its this one...

Undefined symbols for architecture x86_64:
  "_libiconv_open", referenced from:
      _t in conftest-8cc6eb.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

looks like a 32-bit library?

[lamont-granquist]

file seems to think its fine:

% 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

[lamont-granquist]

Ah, I've finally got it. If you've got a /usr/local/include/iconv.h then clang will pick that up and translate iconv_open to libiconv_open and then it fails to find that symbol in /usr/lib/libiconv.dylib. Why clang is doing that is unknown. The iconv.h is there from force linking the header files, which does not need to be done. deleting /usr/local/include/libiconv.h fixes the problem.

[knu]

Let's work out a way with the latest code and information in #1111.