Re: [bug-gnu-libiconv] Including libiconv in another package

[Reuben Thomas]

On Mon, 3 Apr 2023 at 23:21, Bruno Haible <bruno@clisp.org> wrote:

Reuben Thomas wrote:
> > b) if you need GNU libiconv installed on glibc systems.
>
>
> Exactly, as I already said: I want to depend specifically on GNU libiconv
> so I can rely on its behaviour.
>
> So it sounds like I have to get back to statically-linked libiconv then
> work out how to make it work on Windows.

Yes, that's the right approach.

I finally found the courage(!) to dig the commit out of my reflog that had my previous attempt to statically link GNU libiconv into recode.

I have pushed this as https://github.com/rrthomas/recode/tree/static-iconv

Currently the build (seems to) work fine on GNU/Linux and macOS, but fails on Windows: https://github.com/rrthomas/recode/actions/runs/5067900972/jobs/9099522251

I confess that I don't understand what is going on here: recode's configure seems to be trying to configure libiconv/libcharset. I don't know why it does that on Windows, nor why it doesn't on GNU/Linux and macOS.

I'll be very grateful for any help you can give! I hope the approach (to statically link libiconv, installed with "make install-lib" is at least correct now.

I look forward to getting past this build system pain and into implementing some improvements to Recode, such as the one you proposed recently. With a known iconv "under the hood" I look forward to being able to remove Recode's own support for character sets that are perfectly well supported by GNU libiconv, and concentrating on what Recode can do that libiconv can't.

--

https://rrt.sc3d.org