[seanreque]

when I run GtKDtests.exe, the following error pops up in a window:

The procedure entry point libiconv_set_relocation_prefix could not be located in the dynamic link library icomv.dll

I built the libraries using the compdgtkDTests.bat script. I could not get dsss or bud to build the files properly. I have installed the latest gtk runtime libraries. I also searched for the entry point in the dll using vim and found the exact matching string.

I have to say, I am a little disappointed as to how difficult building the project has been so far! Any help would be much appreciated.

[JJR]

Congratualations, you have just experienced what is commonly referred to as "dll hell" on windows.

Unfortunately windows suffers from dll version conflicts if you have have installed software that provides their own version of iconv.dll. I ran into this problem myself with GtkD... unfortunately, I've lost track of the forum post where I discussed it.

This is not really gtkd's fault. What is happening is that the iconv.dll in your Gtk+ install directory is not being loaded because some older version is already in memory, having been loaded by some other piece of software running on your system. The result is that the Gtk+ dll's try to use the already loaded iconv.dll and find it lacking. Examples of other software that use iconv.dll are dsss (which actually uses libiconv2.dll, so that shouldn't be the problem), svn, cvs (NT), git, and many others.

So what you've got to do is find out which of these pieces of software is loading their own iconv.dll first when your system starts up. Usually one these programs is put in your environment path first...so there search directory is the first to be searched for dll or exe dependencies (by the system). You can prevent that particular iconv.dll from being the first to load if you rearrange your PATH environment variable such that the GTK runtime directory (the "lib" directory for most recent versions: it has all the dll's in it) is moved before all other instances in the PATH. This will cause the system to look at iconv.dll in the GTK path first and thus the most up to date version will be accessed first by the other GTK dll's

If this sounds like a royal pain, you'd be right. It's not GtkD's fault, it's the pathetic name/version handicap of the Win32 dynamic library system. I'm not quite sure of a solution for this one. GtkD could possibly help diagnose the problem by doing some tricky investigation in the dll, but I'm really not sure how reliable that will be.

Incidentally, if you're curious to know how many different versions of iconv.dll you have on your system, try doing a windows search with that file name. You might be surprised.

I hope that helps a bit. There's a bunch of us here that are really hoping to make GtkD a good, solid package. We are intent on making things work well and cleanly... but it's an uphill battle and we're just starting to roll.

-JJR

[okibi]

Not that it would help the OP at all, but I'm asking JJR.

Would it be helpful to post a GTK+ runtime installer for windows that I currently use (while I'm on Winblows, that is)? It's a custom 2.12.3 build.

As for the OP, JJR is right. I would recommend placing your GTK+ iconv.dll located in the GTK directory first in your system path and go from there.

[JJR]

[seanreque]

Thanks for your help! I changed my path as you suggested and installed the latest dll's. They correctly load now and the test runs.

[JJR]

Great to hear that it's working, seanreque!

[okibi]

Congrats, seanreque!

JJR, the build is a custom selection of packages from the GTK team's releases, all using official win32 builds. The only change is the xml.lang file in the included sourceview package. I just didn't like the colors!

This will be the official supported package for GtkD. You can download the installer at the following location:

http://www.ratedo.com/ddev/files/GTK-2.12.3.exe

or

http://www.ratedo.com/ddev/files/GTK-2.12.3.zip (in case you can't download .exe files.)

[JJR]

Great! Thanks, okibi.