gtk arch issues

[FoxyBrown via Digitalmars-d-learn]

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.