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

[Bruno Haible]

Hi Reuben,

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

> 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 guess two options are i) somehow build libiconv as a convenience library
> (can I do that without patching its build system?)

Building with libtool and --disable-shared is equivalent to building
a .a file without libtool. It's just that the .a file will be in a slightly
different location, and you will have a .la file that you can ignore.

> or ii) build the shared library but install it in pkglibdir.

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.

> I've successfully implemented option ii) on GNU/Linux, I'm currently stuck
> on getting it working on macOS.

ii) is not an option. It is bound to cause lots of trouble to anyone who
has libiconv installed in the default way (i.e. with mingw as a DLL).

> I guess another option is simply to declare a dependency on GNU libiconv,
> and to require it is installed *somewhere*, and make that the user's
> problem (including communicating where it is installed to Recode's build
> system), but that doesn't seem very nice.

Why is that not "very nice"? Dependencies are normal. When someone builds
GNU libunistring, they need GNU libiconv first. When someone builds GNU guile,
they need GNU libunistring and libgc first. When someone builds libgc,
they may need libatomic_ops first. And so on.

The only real problems with that would occur
a) if recode wants to invoke non-public APIs of GNU libiconv. Is that the case?
b) if you need GNU libiconv installed on glibc systems. This is a no-no,
   since it would cause trouble to users (due to 2 different <iconv.h> files,
   leading to link errors).
   On glibc systems, you thus have only 3 choices:
     - Use iconv from glibc,
     - Package libiconv into librecode.so, and do NOT install iconv.h nor
       libiconv.{a,so} in public locations, or
     - Don't use iconv at all.

Bruno