On Wednesday, 2 August 2017 at 14:59:39 UTC, Mike Wey wrote:
On 01-08-17 22:50, Johnson Jones wrote:
So, the problem is simple(but unfortunately a lot of wasted
time). gtkD needs to be updated to work well with x64 and x86.
I think all one has to do is be able to specify which path of
gtk to use rather than have it search the windows path.
While I could manually rename the dirs or create a script that
does so, that seems harsh. It would be nice if we could
simply set a path in D that gtkD attempts to use as a base
path to load the dlls.
That way, we can completely avoid windows path if necessary
and simply use d's version to set the correct path to the
correct dlls.
(or modified gtkD to work properly with both versions
installed instead of crapping out on the first instance of the
dll it comes across if it is not correct... I'd actually
prefer both ways implemented though so gtkD works better on
the end user's end but I have more control when developing).
I currently have 3.22 32bit 3.22 64bit and 2.14 installed side
by side without any issues. I guess i'll have to try this on a
fresh install of Windows in case i forgot about some changes i
may have made to the system.
If you do this you might want to install gtkD and gtk x64 first,
then x86 right after and then test, as this is what I did. I also
installed visual studio 2017 full(with all the extras which
installed things like gtksharp) before hand along with visual D.
I'm pretty sure that whatever the problems, being able to specify
the path to use for gtk, at least in debug mode, is the way to go
because it gives the programmer the option to bypass all this
nonsense if necessary. Obviously having gtkD resolve the dll's
properly is ideal but it seems that even if that is the case, gtk
itself doesn't do that, so it then becomes pointless ;/
I suppose, maybing adding a build event that rejunctions the gtk
dir to point to the correct version is ideal unless gtk does look
in the it's own dir before checking the path for other dlls,
else, it still might use the wrong dlls.
e.g., we tell gtkd to use gtkx86 but the path is set to use
gtk=>gtkx64. GtkD loads the correct dll's but then some of those
dll's search the path and end up loading the x64 versions. This
is out of gtkd's control unless they petition gtk to fix their
own problems. OTH, if gtk first checks the directory that the dll
is in and tries that(sorta like how an exe will first looking in
it's own dir for the dll's it needs), then it should work.
