View previous topic :: View next topic |
Author |
Message |
seanreque
Joined: 03 Jan 2008 Posts: 2
|
Posted: Thu Jan 03, 2008 5:43 pm Post subject: GtkDTests do not load win32 GTK dll's properly |
|
|
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. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Thu Jan 03, 2008 6:48 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
okibi
Joined: 04 Jan 2007 Posts: 170
|
Posted: Fri Jan 04, 2008 4:50 am Post subject: |
|
|
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. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Jan 04, 2008 10:53 am Post subject: |
|
|
okibi wrote: | 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.
|
Is there a standard gtk+ installer distribution (of 2.12.3) on line that we could link to? I agree that we should, at the very least, post a link on the gtkd wiki to a working installer for win32. Then we can base all gtkd support on the gtk version we've linked too... it would remove all the variances of trying to help people that are grabbing different versions/distributions of gtk+ win32 and then trying to use gtkd.
As for your custom build, do you think that's a good idea to use that instead of linking to an official installer? What did you change in the custom build that makes it different? Should we prefer it over the official one? Just curious.
-JJR |
|
Back to top |
|
|
seanreque
Joined: 03 Jan 2008 Posts: 2
|
Posted: Fri Jan 04, 2008 12:27 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Jan 04, 2008 1:10 pm Post subject: |
|
|
Great to hear that it's working, seanreque! |
|
Back to top |
|
|
okibi
Joined: 04 Jan 2007 Posts: 170
|
Posted: Fri Jan 04, 2008 7:31 pm Post subject: |
|
|
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.) |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Jan 04, 2008 8:33 pm Post subject: |
|
|
Great! Thanks, okibi. |
|
Back to top |
|
|
|