From: Iain Barnett <iainspeed@...>
Date: 2011-03-29T17:29:01+09:00
Subject: Re: mkmf have_func usage


On 28 Mar 2011, at 22:51, Daniel Berger wrote:

> 
> Indeed, I tested this on my Linux box and it works fine with
> "have_func('iconv_open', '/usr/include/iconv.h')".
> 
> Based on the output of the mkmf.log file, I suspect a linkage issue.
> 
> Does it work if you try "have_library('iconv')" or
> "have_library('libiconv')" first?

from my irb:

require "mkmf"
=> true

have_library('iconv')
checking for main() in -liconv... yes
=> true

have_func('iconv_open', '/Library/Frameworks/Libiconv.framework/Versions/1.13.1/include/inconv.h')
checking for iconv_open() in /Library/Frameworks/Libiconv.framework/Versions/1.13.1/include/inconv.h... no
=> false


> 
> I'm also curious why those headers are under /Library/Frameworks, but
> that's another story I suppose.
> 

Because that's where user built libraries on a Mac are "supposed" to go :) 

http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

I stick all my stuff there, it's much easier to use that /usr/local that way.

Where it does fall down is when library writers assume that everyone uses /usr/local. I struggle to think of a worse code smell right now than hard-coded paths for nix systems, but maybe that's just because it's affecting me. Taking a tip from the author(s) of nokogiri I hardcoded the paths to my libs in extconf.rb and it started to build fine, until another hard-coded path in another part of the code borked everything. When I get some time I'll track it down.

Regards,
Iain