gtk arch issues(fixed)

[Johnson Jones via Digitalmars-d-learn]

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.