cardpeek should use iconv.m4 to determine how to link against iconv

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build cardpeek on a system that doesn't have iconv_open in libc, such as 
FreeBSD, OS X, ...
2. configure will fail to find iconv_open (but happily continue without it)
3. cardpeek executable will fail to link because the iconv symbols are missing

What is the expected output? What do you see instead?
Configure should automatically detect that `-liconv` is needed on BSDish 
systems.

What version of the product are you using? On what operating system?
cardpeek 0.8.2, OS X 10.9 Mavericks, Command Line Tools installed

Please provide any additional information below.
The problem can be fixed by using iconv.m4 from the gettext package:
 1. $> mkdir m4
 2. $> cp /usr/share/aclocal/iconv.m4 m4
 3. $> touch config.rpath # needed by iconv.m4, but not present, can be empty
 4. Apply the attached patch to configure.ac and Makefile.am
 5. $> autoreconf -fvi

NB: cardpeek is now available through MacPorts on OS X: 
https://trac.macports.org/ticket/42597.

Original issue reported on code.google.com by neverpa...@gmail.com on 23 Feb 2014 at 8:46

Attachments:

• cardpeek-bsd-libiconv.diff

[GoogleCodeExporter]

Hum, I'm having problems reproducing the problem you describe.

Actually I do most of the development of Cardpeek on OS X 10.9 Mavericks and 
configure works fine on my system. Compilation uses -liconv in my case without 
problem. 

Currently, configure currently first checks for icon_open in -liconv and then 
also in libc. Perhaps there's an issue in the way the linking options are 
passed down to the Makefile in the case where -liconv is needed. In my case, 
LIB contains -liconv.

Could you provide me your config.log and Makefile so that I can check out 
what's going on?

Original comment by L...@gmx.com on 24 Feb 2014 at 9:35

[GoogleCodeExporter]

Thanks for reminding me; I did see your reply but deferred answering it and 
then forgot about it.

I've attached my config.log and the build log of the failed build resulting 
from the check. The problem is that MacPorts-built GNU libiconv doesn't have an 
iconv_open symbol (like the Apple one has), but a libiconv_open symbol and a 
corresponding #define iconv_open libiconv_open in iconv.h, which you are not 
including in your test. iconv.m4 seems to get this right.

Original comment by neverpa...@gmail.com on 25 Feb 2014 at 10:20

Attachments:

• config.log
• main.log

[GoogleCodeExporter]

Also, your test should probably fail if it can't find iconv_open with and 
without `-liconv`, but doesn't and just continues without the flag.

Original comment by neverpa...@gmail.com on 25 Feb 2014 at 10:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Many thanks. Your explanation which narrows down the issue to the handling of 
icon by MacPorts clarifies things a lot.

Original comment by L...@gmx.com on 25 Feb 2014 at 11:53

• Changed state: Started

[GoogleCodeExporter]

This issues is now addressed in the latest SVN release (554) and will be 
distributed in the next release of card peek.
I had to copy more than just iconv.m4 in the m4/ subdirectory, adding 
lib-ld.m4, lib-link.m4, lib-prefix.m4.
Further testing will be needed, but I will close the issue for now.

Original comment by L...@gmx.com on 27 Apr 2014 at 2:13

• Changed state: Fixed