[gimpwin-dev] Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Tor Lillqvist <tml iki fi>]

James Michael DuPont writes:
> lets look for iconv :
> http://sourceforge.net/projects/libiconv/  -- This is from Haible 
> http://savannah.gnu.org/projects/libiconv  -- Oh another one!
> http://gettext.sourceforge.net/            -- another port!
> http://sourceforge.net/projects/mingwrep/  -- Your Package
> http://www.gnu.org/software/libiconv/      -- The GNU Package
> http://sourceforge.net/projects/gnuwin32/  -- The One I used
> http://www.gimp.org/~tml/gimp/win32/downloads.html -- Contains links to
> the gnu package, but not to yours.

"The gnu package" being libiconv's official home, so of course there
is a link to that page???

> http://sourceforge.net/projects/gettext/   -- And the gettext.
>
> http://cygwin.com/cgi-bin2/package-cat.cgi?file=libiconv/libiconv-1.8-2-src&grep=iconv

> So we have a least six different distributions,

Not all of those are binary distributions.

> Now, how am I to know what to use? 

This has indeed been sometimes a problem for me too, for this and
other packages. Something needs to be done, and I will gladly start by
dropping my binary "distribution" of libiconv and instead point to one
of the others. Probably the http://gettext.sourceforge.net/ one, as it
has a DLL (instead of a static archive), and with the same name as I
have used, and there thus won't be any change visible to the users of
the DLL.

As an excuse for having an own binary "distribution" of libiconv I can
just say that when I first needed it, I couldn't find a suitable
binary Win32 distribution to use. But things now have changed.

For me, an ideal binary distribution of a library for Win32 should
fill the following criteria:

- Unless the library is very small, it should be built as a DLL

- If the library's API and ABI is guaranteed to only get extended, and
never to change incompatibly, the DLL name need not be
versioned. Otherwise a version number should be included in the DLL
name. (Note that the version number in the DLL name need not have any
relationship to the software's version number as a whole, but can be
similar to what's used in ELF shared library names.)

- If you do use versioning in the DLL name, increase he version number
only if you introduce backward incompatibilities. Not if you just add
interfaces.

- The import library need not, and should not in most cases, have
versioning in its name. Rationale: On ELF systems, you typically have:

libfoo.so -> libfoo.so.x
libfoo.so.x

No import libraries on ELF, but symlinks, the end result being that
you link with -lfoo. Correspondingly, on Win32, you should also link
with -lfoo (or foo.lib), and this import library then links to
libfoo-x.dll (or whatever naming convention you use; libtool uses
that.)

- The DLL should be useable both from gcc- and MSVC-compiled
code. This means that if the API includes structs that have bitfields,
if building with gcc, one should use -fnative-struct. For most
libraries, this is not a problem. The header files should not include
headers found only on mingw.

- There should be separate "runtime", "developer", and "source"
packages. For small libraries, the first two can well be combined. But
please don't force everybody to download and install source files,
even if you of course should provide sources in the same location as
the binaries. (Yes, I know I have occasionally sinned against this,
and only provided links to sources on other sites. I will follow the
(L)GPL more closely in the future.)

- The developer package should include import libraries both for gcc
and MSVC. Or at least the .def file so that the end-developer can
generate an import library for the compiler of her choice. Note that
if you build with MSVC, the .lib file can be used as such also by
gcc. (Perhaps copy foo.lib to libfoo.a just for tradition.) But if you
build with gcc, you need Microsoft's lib.exe to build the .lib file.

The reason I have until now distributed own versions of libpng,
libjpeg and some others is that I, at the time when I needed those,
couldn't find suitable binary distributions that would have been good
enough from my point of view. But things have improved since then, and
I really should go through this stuff and drop my own versions when
possible.

--tml