On Thursday, 12 December 2013 at 03:17:29 UTC, Malkierian wrote:
On Tuesday, 10 December 2013 at 03:42:10 UTC, Malkierian wrote:
On Tuesday, 10 December 2013 at 02:05:12 UTC, Jeremy DeHaan
wrote:
On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote:
On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan
wrote:
On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian
wrote:
*sigh* No dice. And I can't get GtkD to work either,
because of entry point errors...
I've gotten GtkD to work for me, though it has been a
while. If I am able to find some time soon I will see if I
can do some kind of example for you.
Well, in the mean time, have you ever heard of this error
before?
"The procedure entry point gdk_frame_clock_begin_updating
could not be located in the dynamic link library
libgdk-3-0.dll.
I've also gotten a similar error with some other entry point
in libgdk_pixbuf-2.0-0.dll, but then I copied that file from
the Gtk 3.6.4 release into my bin folder and it went away.
Copying the the libgdk-3-0.dll from the same release did
nothing to fix this error. This is getting ridiculous.
I don't know if this is your problem exactly, but the Gtk+
installer on the GtkD website(http://gtkd.org/download.html)
is for 3.8.1, so maybe something has been updated since then?
You could also open an issue on GtkD's github
repo(https://github.com/gtkd-developers/GtkD) if you continue
to experience problems with it.
LOL, that was the version I was replacing with the 3.6.4 stuff
XD. And I already made a post on their forum about it.
So guess what? I just recently was trying to troubleshoot
GtkD, and in the process I removed the bin folders for the
64-bit versions of TortoiseGit and TortioseSVN from my PATH,
and when I switch back over to my other source set (the one
with the file chooser from here) suddenly the windows generic
chooser works fine. I had to remove those two bin folders from
the path because, despite it being a 32-bit application, it was
apparently loading (or trying to load) a specific driver from
those folders that was messing everything up.
So is this 32/64-bit crossover thing a bug in D, or is it just
a phantom random weird thing that was happening with my setup?
Mixing 32 bit code with 64 bit libraries, or vice versa, is (from
what I have read) not usually a good thing and is not specific to
the D language. If your program found a dll with the same name
for one it is looking for I think it just goes for it. I have no
idea if Windows can or does try to verify how many bits a library
has before it loads it.
