iconv.dll should be libiconv.dll??

Cameron Gregory writes:
 > libconv-1.7.zip contains iconv.dll, but shouldn't
 > it be libiconv.dll? Or libiconv-0.dll?

iconv.dll is the name that the makefile in the iconv source package
uses, I haven't changed it. In fact, currently I don't even distribute
an iconv package I would have built myself; If you check the downloads
page, there is a link to another site where libiconv binary and source
packages are downloadable. (See the threads started by James Michael
DuPont.)

The "lib" prefix is just a Unixish convention that libtool follows,
and the "-0" suffix (or similar) would be necessary if the API and ABI
of libiconv was subject to change. But apparently the libiconv author
thinks there is little risk for that. (Or if it would change
incompatibly, then the new version would use some new name for the
DLL, like iconv2.dll or something.)

 > I get a big warning if I it's not called libiconv.dll
 > (below),

Hmm. I don't know why that is. I have seen those warnings, too, but
not currently. But presumably you can ignore it.

 > Also, libconf-1.7-dev.zip appears to be missing libiconv.dll.a
 > Although I guess nobody is using that... (but most of the other
 > libraries appear to have it)

there is (was) a libiconv.a, wasn't there? That is enough. The
.dll. part of the libfoo.dll.a name is just libtool's convention. (And
when GNU ld looks for the library file corresponding to a -lfoo
switch, I think it looks for at least the combinations libfoo.a,
libfoo.dll.a, foo.lib, foo.dll and perhaps libfoo.dll. Check ld
documentation to be sure.)

 > (all of tml's .zip files are extracted to /target)

That shouldn't be necessary. The intention is that they should work
regardless of where you put them, as long as you put all in the same
place. I am pretty confident that it should work wherever you put
them. If you use /target, too, this won't get tested...

--tml