HAVE_ICONV not getting set on Mac OS X

[pmetzger]

Just like it says on the label. On OS X, config.h.in starts with HAVE_ICONV undef'ed and nothing ever fixes that. There doesn't even seem to be any code generated to try to figure out if ICONV is present. I've been trying to figure out how this is happening and so far I'm at a loss, but it's preventing builds of the latest release.

UPDATE: I seem to have failed to mention that you need to autogen.sh with --enable-iconv for this to be an issue in the first place.

[dinhvh]

Did you try to open the Xcode project in build-mac and build it? What did you try?

[pmetzger]

I'm updating the MacPorts port. That doesn't (and can't) use the Xcode project, it uses autotools just like one would under Linux. Everything builds and works totally fine if I hand-edit HAVE_ICONV to be defined in config.h, but otherwise it fails utterly.

[pmetzger]

(I'm tempted to kludge this by forcing a script to patch the HAVE_ICONV variable but that seems entirely wrong to me.)

[dinhvh]

Did you try to debug the configure script to figure out why it wouldn't detect iconv?

[pmetzger]

The reason is straightforward though the cause of it is inexplicable. The configure script never gets any code to try to detect ICONV in the first place. I'm happy to supply you with gists of the resulting files (and logs).

[pmetzger]

(On the other hand, if you have a Mac, you can probably see the results yourself quite quickly. They're very consistent.)

[pmetzger]

I'm tempted to just put in a horrid kludge (like a script that blasts the undefine in the generated include file) so I can finish updating the port in Macports. It isn't the right thing but I'm guessing it's the practical solution, short of my learning Autoconf myself which I don't want to do.

[dinhvh]

Go ahead and put in the kludge in the macports (you probably need to get it done). I'll investigate it later in libetpan.

[pmetzger]

To reproduce the problem on macOS Sierra:

1. Fetch 1.8 and unpack it.
2. ./autogen.sh --enable-iconv
3. make

You will then get a compile failure in parser.c

[dinhvh]

Could you show what build failure you got?

[pmetzger]

Gist link with build failure attached. Explanation of it below:

so to reproduce this, after unpacking, I ran (on sierra): ./autogen.sh --enable-iconv and then make

The make dies, and the end of the output, when it dies, is located here: https://gist.github.com/pmetzger/f729f2c28cc7ec964e79646a380e5943

And again, if you hand-edit the config.h file after the autogen step to #define HAVE_ICONV everything works right, but this is clearly not the correct thing to do.

I will happily supply any files you need to examine if you don't have a Mac to reproduce this yourself, but I was under the impression you were a mac user.

[pmetzger]

Full output of the autogen and compile phases attached in case more than just the end of the make phase is useful:

make.txt autogen.txt

[romeojulietthotel]

This looks like two problems.

Problem 1: Looking at @pmetzger https://gist.github.com/pmetzger/f729f2c28cc7ec964e79646a380e5943#file-gistfile1-txt-L3

static void elparse_end_dummy(void * data, const char * el)

parser.c:135:57: warning: unused parameter 'el' [-Wunused-parameter]

So elparse_end_dummy needs to be fixed. I haven't looked to see if there are any users of that but those users would also need fixing. Or remove elparse_end_dummy .

@dinhviethoa might be a good time to review all that since it looks like elparse_end_dummy has always been that way.

Problem 2:

I'm building on linux and using ./configure --disable-iconv

The

feed/parser.c

looks to need ifdef fixing to honor the --disable-iconv flag.