On Tuesday, 1 August 2017 at 21:03:44 UTC, Mike Wey wrote:
On 01-08-17 22:16, Johnson Jones wrote:
nvm, the file exists. Why it is not being found is unknown.
I did some stuff and it says it is not a valid win32, this is
using that gtk3 runtime I linked to... says it's x64 version
but probably x86.
Would be nice if the error message printed the full path of
what was being loaded so it's quicker to diagnose.
Seems there is a
> ... code ...
which is used, could I just hijack this to set the correct
path based on what version it is compiled under? Would be the
easiest thing, at least as a temporary workaround.
You renamed the gtk DLL's, i assume you simply renamed them,
but to get things working with different names you would need
to build GTK from source, and apply the appropriate patches to
GTK and its make files.
I rebuilt gtkD but obviously not gtk, which I guess was using
searching the dll's the same way that gtkD did.
If you would use a dependency walker on libgtk-3-0.dll you can
see that it depends on basically all the other dll's in the
directory, and by renaming them they can no longer be found.
For libraries that are in both GTK 3 and GTK 2 it might find
the libraries distributed with gtksharp but that would also
fail because of the version difference.
I didn't actually rename, I copied then renamed the copies so
that the originals were still there. The point was to get gtkD to
use different versions, which it did, but I guess gtk had the
same problem with it's versioning where it would simply try to
use whatever it found in the path.
Printing the full path of the library in the error would only
only be possible if we call LoadLibrary with the full path.
It's been a while since i implemented the architecture check
but if i remember correctly there were some issues with that.
Otherwise it might be loaded from one of the other directories
LoadLibrary searches, and then the printed path would be wrong,
making things even worse.
And yes you could hard code the path that is passed to
SetDllDirectory as a work around, but the dll's will need to
have there proper names.
As I stated the last post, everything is working. I reverted back
to the original gtkD so it uses the original names. I only have
one GTK dir in the path at a time now rather than both x86 and
x64. That solved the problem. The only problem that exists now is
that I have to manually swap the installations of gtkx86 and
gtkx64. When I switch from from x86 to x64 and vice versa... not
difficult but I'm sure I'll forget months down the road and waste
time trying to remember what I needed to do.
So, I have dirs like
C:\Gtkx86
C:\Gtkx64
C:\Gtk
where C:\Gtk is a junction that points to either C:\Gtkx86 or
C:\Gtkx64 depend on which arch I'm compiling for. The path only
as C:\Gtk in it so there is no possibility for the dlls to get
mixed up, which is what happens when both architecture versions
are in the path.
I'd like to avoid having to change the junction each time I
decide to test my app in a different architecture. Instead,
having a simple
version(X86)
SetGTKDir("C:\\Gtkx86");
version(Win64)
SetGTKDir("C:\\Gtkx64");
is what I'm after.