> OK, I've now added $lt_cv_prog_compiler_pic to CFLAGS when building
> (embedded) libiconv. This seems to add -DPIC on MSYS2 (Mingw64). I am
> building with --disable-shared, because I don't want to install a libiconv
> shared library, to avoid conflicts.
Good. This is now as it should be. Try doing this on ELF systems, macOS,
and Cygwin.
I did that for ELF and macOS (not Cygwin, which I don't test).
> However, libtool can't link a static
> library into a shared library on mingw64.
This can be fixed afterwards. First, I would make sure that the approach
works in general. Native Windows often needs special hacks. By porting
to Windows first, one often makes bad decisions.
I didn't, I ported to macOS first.
Please, no! This would directly conflict with libiconv's installation
because as soon as a user has $libdir and recode's $pkglibdir in the
same LD_LIBRARY_PATH (or on Windows, PATH), there will be two libraries
with the same soname visible.
OK, I'll undo this and see where I got to. Annoyingly I already squashed some commits, because I thought the static linking approach wouldn't work.
Why is that not "very nice"?
Because an alternative libiconv is awkward to install on a system that already has iconv.
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.
Truly, this is all a major PITA, it was simpler when recode just had an internal copy of GNU libiconv.