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

[Bruno Haible]

Hi Reuben,

> I look forward to getting past this build system pain

Let me see if I can help...

> 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

During the 'bootstrap' of this directory I see warnings:

bootstrap: running: git submodule init -- gnulib
Submodule 'gnulib' (git://git.sv.gnu.org/gnulib.git) registered for path 
'gnulib'
bootstrap: running: git submodule update -- gnulib
Submodule path 'gnulib': checked out 'eecd8afd696055cf39ef934208724bfe850c5760'
bootstrap: running: git submodule init -- gl-mod/bootstrap:libiconv
error: pathspec 'gl-mod/bootstrap:libiconv' did not match any file(s) known to 
git
bootstrap: running: git submodule update -- gl-mod/bootstrap:libiconv
error: pathspec 'gl-mod/bootstrap:libiconv' did not match any file(s) known to 
git

git (at least version 2.34.1 that I use) does not understand this syntax.
When I use separate commands
  git submodule init -- gl-mod/bootstrap
  git submodule update -- gl-mod/bootstrap
  git submodule init -- libiconv
  git submodule update -- libiconv
then, after some minor hassle, I get the submodule 'libiconv' installed and
checked out.

> 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 don't use MSYS2, therefore I won't attempt to reproduce this. It looks like
some directory name was transformed in an invalid way and then not found on
disk.

But I could run "make distcheck" on Linux and then attempt to build the tarball
on my usual build environments on Windows (mingw and msvc, both accessed from
a Cygwin environment).

You find the results attached.

1) In both cases, the configuration gets past the "=== configuring in 
libcharset"
line.

> 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 see a line "=== configuring in libcharset" also on Linux.

Why it does that? Configuration of recode should trigger a configuration
of libiconv, and the configuration of libiconv triggers a configuration of
libcharset (since libiconv/configure.ac contains
  AC_CONFIG_SUBDIRS([libcharset])
).

So, this is all normal, except that you are hitting an MSYS2 wart.

2) In the build-msvc64/log1 I see a compilation error: the gnulib-generated
libiconv/srclib/stddef.h attempts to
  #include ""
That include file name was stuffed there from the libiconv/srclib/Makefile
(build-msvc64/log1 line 1625). So it appears that NEXT_STDDEF_H expanded to
the empty string. But in libiconv/config.status I see that
NEXT_STDDEF_H is associated with a correct long file name.
Why is that? It's because libiconv/config.status is newer than
libiconv/srclib/Makefile !

Also, it is very unusual/strange that the *configuration* of recode
triggers a *build* of libiconv. This is most likely the cause of the
wrong dates of libiconv/config.status vs. libiconv/srclib/Makefile,
and is also likely to cause other problems (think of "make clean",
which is not meant to erase files created by 'configure' ...).
I don't remember if it was me who suggested doing that. But it looks
very wrong. The right approach is:
  - configure of recode should trigger a configure of libiconv, via
    AC_CONFIG_SUBDIRS,
  - "make" of recode should trigger a "make" of libiconv,
  - configure of recode cannot use AM_ICONV or other configure tests
    which assume that libiconv is already built and installed.

3) The build on mingw went even farther, but then encountered a link
error, apparently due to a iconv_open vs. libiconv_open confusion
(perhaps a wrong <iconv.h> being used?).

I would suggest to fix the issue 2) before looking into 3).

> 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.

+1.

Bruno

recode-windows-logs.tar.gz
Description: application/compressed-tar