libiconv: iconv_open is missing?

[Matt Wynne]

I'm relatively new to unix/osx/ruby so please be as gentle as you
can...!

I'm running Mac OSX Tiger.

When I run ruby extconf.rb to try and install net-geoip-0.06 I keep
getting the error 'extconf failure: need libiconv.'

I'm pretty stuck with this. I have un-installed ruby and libiconv then
reinstalled, all using DarwinPorts. If I run port installed i see the
following:
Vigor10:~/Documents/Downloads/net-geoip-0.06 matt$ port installed
The following ports are currently installed:
libiconv @1.11_0+darwin_8 (active)
openssl @0.9.8b_0+darwin_8 (active)
readline @5.1.004_0 (active)
ruby @1.8.5_0 (active)
sqlite2 @2.8.17_0+darwin_8 (active)
sqlite3 @3.3.7_0+darwin_8 (active)
swig @1.3.29_0+darwin_8 (active)
zlib @1.2.3_0 (active)

So that looks OK, right?

In irb, if I require('mkmf') first, I can call
have_library('iconv','libiconv') and return true, but the line that
fails in extconf.rb is looking for a function 'iconv_open', and indeed
if i call find_library('iconv','iconv_open') in that same irb session, I
get back false.

I saw another discussion on here[1] about the lib-xml component that
also requires this iconv_open function, and someone who seemed to have
it missing, though I couldn't see a resolution on that thread (at least
not one that I understood!)

Any help immensely appreciated, this is my brick wall right now.

cheers,
Matt


[1]http://www.ruby-forum.com/topic/55709#39835

 

[Bill Kelly]

In irb, if I require('mkmf') first, I can call
have_library('iconv','libiconv') and return true, but the line that
fails in extconf.rb is looking for a function 'iconv_open', and indeed
if i call find_library('iconv','iconv_open') in that same irb session, I
get back false.

Sorry, I don't know the answer, but - have you tried just commenting
out that line in the extconf.rb, and seeing if it might build anyway?

(The thinking was, if you're lucky, if just might build anyway; otherwise
it may fail later in the build, possibly giving additional clues about why
it won't build...)


Regards,

Bill

 

[Nobuyoshi Nakada]

Hi,

At Fri, 20 Oct 2006 08:13:46 +0900,
Matt Wynne wrote in [ruby-talk:220713]:

In irb, if I require('mkmf') first, I can call
have_library('iconv','libiconv') and return true, but the line that

have_library('iconv', 'iconv') fails, right?

fails in extconf.rb is looking for a function 'iconv_open', and indeed
if i call find_library('iconv','iconv_open') in that same irb session, I
get back false.

Then try
find_library('iconv','libiconv')
or
find_library('iconv','libiconv_open')

find_library should take headers parameter as well as have_library,
but it'd be too late.

 

[Matt Wynne]

thanks Nobuyoshi,

Then try
find_library('iconv','libiconv')
or
find_library('iconv','libiconv_open')

yes, both of those work.

Does this mean the extconf.rb file for net-geoip-0.06[1] is incorrect
then? If I hack it to change the 'iconv_open' in that file to
'libiconv_open' instead, will the program still build ok?

find_library should take headers parameter as well as have_library,
but it'd be too late.

I'm sorry I don't understand what you've said here - are you saying it
would be nice to change find_library to have this extra functionality?

cheers,
Matt

 

[Matt Wynne]

Sorry, I don't know the answer, but - have you tried just commenting

out that line in the extconf.rb, and seeing if it might build anyway?

(The thinking was, if you're lucky, if just might build anyway;
otherwise
it may fail later in the build, possibly giving additional clues about
why
it won't build...)

Hey Bill, thanks, I kindof did that by taking Nobuyoshi's suggestion and
hacking the extconf.rb file, which now runs. The make fails though, like
this:

Vigor10:~/Documents/Downloads/net-geoip-0.06 matt$ make
gcc -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin8.8.1 -I.
-DRUBY_EXTCONF_H=\"extconf.h\" -O -pipe -I/opt/local/include -fno-common
-g -Wall-O -pipe -I/opt/local/include -fno-common -pipe -fno-common
-I/opt/local/include -c geoip.c
cc1: error: unrecognized command line option "-Wall-O"
make: *** [geoip.o] Error 1

bummer. I don't expect anyone here on the ruby forums to help me with
this, the link to ruby is rather tenuous now! I'm guessing maybe MaxMind
haven't tried building this on OSX. I've emailed MaxMind support so I'll
see what they say.

Any tips on where else I might be able to ask for help with this gcc
issue?

cheers,
Matt

 

[Bill Kelly]

Hey Bill, thanks, I kindof did that by taking Nobuyoshi's suggestion and
hacking the extconf.rb file, which now runs. The make fails though, like
this:

Vigor10:~/Documents/Downloads/net-geoip-0.06 matt$ make
gcc -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin8.8.1 -I.
-DRUBY_EXTCONF_H=\"extconf.h\" -O -pipe -I/opt/local/include -fno-common
-g -Wall-O -pipe -I/opt/local/include -fno-common -pipe -fno-common
-I/opt/local/include -c geoip.c
cc1: error: unrecognized command line option "-Wall-O"
make: *** [geoip.o] Error 1

It looks like part of your compiler flags string was appended to itself, for
some reason. Or sort of, anyway:

See how "-O -pipe -I/opt/local/include -fno-common" appears twice?
But it was appended the second time without a space, so that the "-O"
is touching the "-Wall".

At the very least, you'd want a space between the "-Wall" and the "-O",
to prevent them from touching and combining to form an unrecognized
option.

Hard to guess from here how that compiler command line string is being
generated... it contains a fair amount of duplication. But anyway, the
immediate problem is that the "-O" is touching the "-Wall", instead of
being separated by a space.

HTH,

Bill

 

[Matt Wynne]

See how "-O -pipe -I/opt/local/include -fno-common" appears twice?

But it was appended the second time without a space, so that the "-O"
is touching the "-Wall".

At the very least, you'd want a space between the "-Wall" and the "-O",
to prevent them from touching and combining to form an unrecognized
option.

Very sharp Bill, I should have spotted that myself. It turns out I don't
need this component for my project after all, so I'm just dropping the
problem. Thanks again for your friendly assistance though guys!

cheers,
Matt