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 _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
