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.

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.

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.

-- 
Mike Wey

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.

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.

-- 
Mike Wey

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.