Re: iconv.dll should be libiconv.dll??
Cameron Gregory <[email protected]>
| Newsgroups | gmane.comp.video.gimp.windows.devel |
|---|---|
| Message-ID | <[email protected]> |
Tor Lillqvist wrote: > > 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.) > ahh .. I was using the ones that you did previous distribute. > > 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 umm .. no, not in your old one, or the new one. (libiconv-1.7-w32.bin.zip) I'm downloading the source now, should be easy enough to rename to libiconv and try it... > 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.) cool. Yeah, part of my troubles is I'm not up on the ways of win32, nor the whole automake process. I'm used to regular make files, and writing code... :-) > > (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... yep, but there are already too many variables. I'm just trying to settle things down as much as possible, and try to get to the point I really want. (to be able to make source code changes). I have been making some changes, but so far only to check out what is going wrong. At the moment plug_in_path is NULL. catch ya, Cameron > > --tml > > > To Post a message, send it to: [email protected] > To Unsubscribe, send a blank message to: [email protected] > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -- Please include previous messages in reply so I can follow the thread. --------------------------------------------------------------------- Cameron Gregory http://www.flamingtext.com/ [email protected]