www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - gtk arch issues

reply Johnson Jones <JJ Dynomite.com> writes:
how does one allow both gtk x86 and x64 to work side by side 
seamlessly?

I installed x64 first and it seems, because whatever is using the 
path to find the gtk runtime, it looks for that first even in x86 
build.

Seems like gtkd's dll resolution is not very intelligent. While I 
could manually modify the path each time I switch archs, that 
seems pointless.

One of the problems in gtkd is that it has multiple places where 
it defines libgdk-3-0.dll.


I've tried modifying gdkD so that it uses versioning properly by 
searching for libgdk-3-0.dll and changing all to use an x86 or 
x64 when appropriate but that doesn't seem to help. Probably have 
to rebuild gtkD.

Anyways, doesn't seem to be a great solution ;/ Any ideas and 
maybe someone can add an issue to the github page to get this 
fixed? (I can't do it for a while because of other issues).
Jul 31
next sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
On Monday, 31 July 2017 at 17:16:32 UTC, Johnson Jones wrote:
 how does one allow both gtk x86 and x64 to work side by side 
 seamlessly?

 I installed x64 first and it seems, because whatever is using 
 the path to find the gtk runtime, it looks for that first even 
 in x86 build.

 Seems like gtkd's dll resolution is not very intelligent. While 
 I could manually modify the path each time I switch archs, that 
 seems pointless.

 One of the problems in gtkd is that it has multiple places 
 where it defines libgdk-3-0.dll.


 I've tried modifying gdkD so that it uses versioning properly 
 by searching for libgdk-3-0.dll and changing all to use an x86 
 or x64 when appropriate but that doesn't seem to help. Probably 
 have to rebuild gtkD.

 Anyways, doesn't seem to be a great solution ;/ Any ideas and 
 maybe someone can add an issue to the github page to get this 
 fixed? (I can't do it for a while because of other issues).
I fixed up gtkd so that it uses x86 and x64 versions of dlls but it doesn't seem to help with x64. I was able to get x86 to compile and run but x64 just loads then quits without any errors ;/ C:\Program Files (x86)\GtkSharp\2.12\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libintl-8.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgobject-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libpango-1.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded. Best I can tell is that something is using the x86 verisons for some reason. Note that all those dll's should be x64 versions, but something outside of gtkD is loading them, I suspect it's Gtk itself, which would require proper versioning ;/ I replaced libgdk_pxbuf in gtkd to version it, i.e., version (Windows) version(X86) static immutable LIBRARY_GDKPIXBUF = ["libgdk_pixbuf-2.0-0x86.dll"]; else static immutable LIBRARY_GDKPIXBUF = ["libgdk_pixbuf-2.0-0x64.dll"]; and rebuilt, but it obviously using using that. It's probably a gtk-runtime dll that is using it that isn't versioned itself ;/ Of course, I want to be able to run my programs in x64 at some point so figuring out what is going on is important. It would be lovely if people would get their act together so things would work properly ;/
Jul 31
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Monday, 31 July 2017 at 17:50:08 UTC, Johnson Jones wrote:
 On Monday, 31 July 2017 at 17:16:32 UTC, Johnson Jones wrote:
 [...]
I fixed up gtkd so that it uses x86 and x64 versions of dlls but it doesn't seem to help with x64. I was able to get x86 to compile and run but x64 just loads then quits without any errors ;/ [...]
Also, why is gtkD even using gtksharp? That's for mono and .net!
Jul 31
parent Mike Wey <mike-wey example.com> writes:
On 31-07-17 19:53, Johnson Jones wrote:
 Also, why is gtkD even using gtksharp? That's for mono and .net!
We don't. only the (C) Gtk runtime is needed. Where did you see gtksharp? -- Mike Wey
Jul 31
prev sibling parent reply Mike Wey <mike-wey example.com> writes:
On 31-07-17 19:16, Johnson Jones wrote:
 how does one allow both gtk x86 and x64 to work side by side seamlessly?
 
 I installed x64 first and it seems, because whatever is using the path 
 to find the gtk runtime, it looks for that first even in x86 build.
 
 Seems like gtkd's dll resolution is not very intelligent. While I could 
 manually modify the path each time I switch archs, that seems pointless.
 
 One of the problems in gtkd is that it has multiple places where it 
 defines libgdk-3-0.dll.
 
 
 I've tried modifying gdkD so that it uses versioning properly by 
 searching for libgdk-3-0.dll and changing all to use an x86 or x64 when 
 appropriate but that doesn't seem to help. Probably have to rebuild gtkD.
 
 Anyways, doesn't seem to be a great solution ;/ Any ideas and maybe 
 someone can add an issue to the github page to get this fixed? (I can't 
 do it for a while because of other issues).
 
At startup GtkD searches the Path for "libgtk-3-0.dll", when it finds one it checks the architecture of the library. If it's the correct architecture it calls `SetDllDirectory` so that the directory with the correct architecture will be searched first by `LoadLibrary`. If it's not the correct architecture it continues searching, if no library with the correct architecture is found, we rely on `LoadLibrary` to error out if the libraries are also not in the other locations searched by `LoadLibrary`. -- Mike Wey
Jul 31
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Monday, 31 July 2017 at 20:37:11 UTC, Mike Wey wrote:
 On 31-07-17 19:16, Johnson Jones wrote:
 how does one allow both gtk x86 and x64 to work side by side 
 seamlessly?
 
 I installed x64 first and it seems, because whatever is using 
 the path to find the gtk runtime, it looks for that first even 
 in x86 build.
 
 Seems like gtkd's dll resolution is not very intelligent. 
 While I could manually modify the path each time I switch 
 archs, that seems pointless.
 
 One of the problems in gtkd is that it has multiple places 
 where it defines libgdk-3-0.dll.
 
 
 I've tried modifying gdkD so that it uses versioning properly 
 by searching for libgdk-3-0.dll and changing all to use an x86 
 or x64 when appropriate but that doesn't seem to help. 
 Probably have to rebuild gtkD.
 
 Anyways, doesn't seem to be a great solution ;/ Any ideas and 
 maybe someone can add an issue to the github page to get this 
 fixed? (I can't do it for a while because of other issues).
 
At startup GtkD searches the Path for "libgtk-3-0.dll", when it finds one it checks the architecture of the library. If it's the correct architecture it calls `SetDllDirectory` so that the directory with the correct architecture will be searched first by `LoadLibrary`. If it's not the correct architecture it continues searching, if no library with the correct architecture is found, we rely on `LoadLibrary` to error out if the libraries are also not in the other locations searched by `LoadLibrary`.
This is not true(at least completely). I have have a fresh windows 10 install with fresh dmd and gtkd and gtk x64 and x86(installed later). When running my app in x64 mode it tried to use the x64 but the app crashed and I didn't know why as no error message and bug in visual D wouldn't allow me to use BP's to find out how far the app was getting. So I decided to install the x86 version. Ran the project in x86 mode but gtkd was trying to load the x64 dlls and told me they were wrong. Remember, now I have both versions on my system. I decided to modify gtkd and using some versioning, in which case this got me to allow x86 to work as it now used *x86.dll's. I noticed that gtksharp was installed in program files (x86). I then tried to build the x64 version and the app just loads then quits but the debug console shows what I pasted and shows that it is trying to load stuff from gtksharp. All I installed as gtk3-runtime_3.22.4_64-bit and gtk3-runtime_3.22.4_32-bit. Now, it may turn out that gtksharp was installed by something else(visual studio? or maybe a few other apps I installed). That seems to be the case as the modified date predates install of gtk3 and seems to correlate to when I installed visual studio 2017 with it's 50+ gigs worth of crap. Why is my x64 app trying to load those files though and specially from the wrong version? the x86 version The files being loaded(I suppose they are, not sure what the unloaded means): C:\Windows\SysWOW64\kernel32.dll unloaded. C:\Windows\SysWOW64\winmmbase.dll unloaded. C:\Windows\SysWOW64\winmmbase.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Windows\SysWOW64\dnsapi.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libpangoft2-1.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk-3-0.dll unloaded. C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.483_none_6dad63fef 436da8\comctl32.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\librsvg-2-2.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libcroco-0.6-3.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libxml2-2.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libxml2-2.dll unloaded. C:\Windows\SysWOW64\winhttp.dll unloaded. C:\Windows\SysWOW64\OnDemandConnRouteHelper.dll unloaded. for x86, for x64 I get C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded. C:\Program Files (x86)\GtkSharp\2.12\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Windows\System32\dwmapi.dll unloaded. C:\Windows\System32\ole32.dll unloaded. C:\Windows\System32\setupapi.dll unloaded. C:\Windows\System32\winmm.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded. The program '[3420] test.exe' has exited with code 1 (0x1). as you can see, some files are loaded that are from x86. Remember, I modified gtk so that it duplicates all the dll's with the x??.dll's and modified gtkd to take those x??.dll's instead, which you can see in the last libgdk-3-0x64. So, those files being loaded are surely not coming from inside gtkd? I modified things like version (Windows) { version(X86) { const string[LIBRARY.max+1] importLibs = [ LIBRARY.ATK: "libatk-1.0-0x86.dll", LIBRARY.CAIRO: "libcairo-2x86.dll", LIBRARY.GDK: "libgdk-3-0x86.dll", LIBRARY.GDKPIXBUF: "libgdk_pixbuf-2.0-0x86.dll", LIBRARY.GLIB: "libglib-2.0-0x86.dll", LIBRARY.GMODULE: "libgmodule-2.0-0x86.dll", LIBRARY.GOBJECT: "libgobject-2.0-0x86.dll", LIBRARY.GIO: "libgio-2.0-0x86.dll", LIBRARY.GTHREAD: "libgthread-2.0-0x86.dll", LIBRARY.GTK: "libgtk-3-0x86.dll", LIBRARY.PANGO: "libpango-1.0-0x86.dll", LIBRARY.PANGOCAIRO: "libpangocairo-1.0-0x86.dll", LIBRARY.GLGDK: "libgdkglext-3.0-0x86.dll", LIBRARY.GLGTK: "libgtkglext-3.0-0x86.dll", LIBRARY.GDA: "libgda-4.0-4x86.dll", LIBRARY.GSV: "libgtksourceview-3.0-0x86.dll", LIBRARY.GSV1: "libgtksourceview-3.0-1x86.dll", LIBRARY.GSTREAMER: "libgstreamer-1.0x86.dll", LIBRARY.GSTINTERFACES: "libgstvideo-1.0x86.dll", LIBRARY.VTE: "libvte-2.91x86.dll", LIBRARY.PEAS: "libpeas-1.0x86.dll", LIBRARY.RSVG: "librsvg-2-2x86.dll", ]; } else { const string[LIBRARY.max+1] importLibs = [ LIBRARY.ATK: "libatk-1.0-0x64.dll", LIBRARY.CAIRO: "libcairo-2x64.dll", LIBRARY.GDK: "libgdk-3-0x64.dll", LIBRARY.GDKPIXBUF: "libgdk_pixbuf-2.0-0x64.dll", LIBRARY.GLIB: "libglib-2.0-0x64.dll", LIBRARY.GMODULE: "libgmodule-2.0-0x64.dll", LIBRARY.GOBJECT: "libgobject-2.0-0x64.dll", LIBRARY.GIO: "libgio-2.0-0x64.dll", LIBRARY.GTHREAD: "libgthread-2.0-0x64.dll", LIBRARY.GTK: "libgtk-3-0x64.dll", LIBRARY.PANGO: "libpango-1.0-0x64.dll", LIBRARY.PANGOCAIRO: "libpangocairo-1.0-0x64.dll", LIBRARY.GLGDK: "libgdkglext-3.0-0x64.dll", LIBRARY.GLGTK: "libgtkglext-3.0-0x64.dll", LIBRARY.GDA: "libgda-4.0-4x64.dll", LIBRARY.GSV: "libgtksourceview-3.0-0x64.dll", LIBRARY.GSV1: "libgtksourceview-3.0-1x64.dll", LIBRARY.GSTREAMER: "libgstreamer-1.0x64.dll", LIBRARY.GSTINTERFACES: "libgstvideo-1.0x64.dll", LIBRARY.VTE: "libvte-2.91x64.dll", LIBRARY.PEAS: "libpeas-1.0x64.dll", LIBRARY.RSVG: "librsvg-2-2x64.dll", ]; } } and version (Windows) { version(X86) static immutable LIBRARY_GDKPIXBUF = ["libgdk_pixbuf-2.0-0x86.dll"]; else static immutable LIBRARY_GDKPIXBUF = ["libgdk_pixbuf-2.0-0x64.dll"]; } So, the question is, is this a gtkd problem or a gtk problem? In either case, what's the way to get them both to work. Do you guys actually test out both versions installed on the same system?
Jul 31
parent reply Mike Wey <mike-wey example.com> writes:
On 01-08-17 01:37, Johnson Jones wrote:
 
 So, the question is, is this a gtkd problem or a gtk problem? In either 
 case, what's the way to get them both to work. Do you guys actually test 
 out both versions installed on the same system?
 
Gtk also loads some of it's own libraries at start up with GModule / LoadLibrary. So with the library names changed GTK might be loading the Gtk 2 libraries installed with gtksharp instead of the correct ones. -- Mike Wey
Aug 01
parent reply Johnson Jones <JJ Dynomite.com> writes:
On Tuesday, 1 August 2017 at 15:14:50 UTC, Mike Wey wrote:
 On 01-08-17 01:37, Johnson Jones wrote:
 
 So, the question is, is this a gtkd problem or a gtk problem? 
 In either case, what's the way to get them both to work. Do 
 you guys actually test out both versions installed on the same 
 system?
 
Gtk also loads some of it's own libraries at start up with GModule / LoadLibrary. So with the library names changed GTK might be loading the Gtk 2 libraries installed with gtksharp instead of the correct ones.
Ok, I renamed Program Files (x86)\GtkSharp so that it effectively deleted it, Same issue though: C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll unloaded. C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded. C:\Windows\System32\dwmapi.dll unloaded. C:\Windows\System32\setupapi.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded. C:\Windows\System32\ole32.dll unloaded. C:\Windows\System32\winmmbase.dll unloaded. C:\Windows\System32\winmm.dll unloaded. C:\Windows\System32\ws2_32.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded. The thread 0x1590 has exited with code 1 (0x1). The thread 0x1598 has exited with code 1 (0x1). The thread 0x1594 has exited with code 1 (0x1). The program '[5472] test.exe' has exited with code 1 (0x1). Renaming Program Files (x86)\Gtk-Runtime Gives C:\Windows\System32\dwmapi.dll unloaded. C:\Windows\System32\setupapi.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded. C:\Windows\System32\ole32.dll unloaded. C:\Windows\System32\winmmbase.dll unloaded. C:\Windows\System32\winmm.dll unloaded. C:\Windows\System32\ws2_32.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgobject-2.0-0.dll unloaded. C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded. The thread 0x1480 has exited with code 1 (0x1). The thread 0x1560 has exited with code 1 (0x1). The thread 0x4f0 has exited with code 1 (0x1). The program '[3936] test.exe' has exited with code 1 (0x1). And x86 test.exe gives the error: "The image File C:\Program Files\Gtk-Runtime\bin\libatk-1.0-0.dll" is valid but is for a machine type other than the current machine. Select Ok to Continue or Cancel to fail the DLL load". which was the original error I got. At this point x64 gives the error: object.Exception generated\gtkd\gtkd\Loader.d(125): Library load failed (libgdk-3-0x64.dll): The specified module could not be found. which has the code: //TODO: A more general way to try more than one version. if ( handle is null && library == importLibs[LIBRARY.GSV] ) handle = pLoadLibrary(importLibs[LIBRARY.GSV1]); Which, if I'm not mistaken, suggests that maybe it is time to add this "more general way" ;) Now, why it is trying to load libgdk-3-0x64.dll, which is clearly one of the modified files, but a dll of gdk, is unclear. I have no file with gdk in it in any of the proper directories. tried installing https://sourceforge.net/projects/gtk3win/files/latest/download but no luck. Says it's for x86 and x64 but I have my doubts. So what is going on here?
Aug 01
next sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
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

	public static void loadLibrary(string library)
	{
		void* handle = pLoadLibrary(library);

		//TODO: A more general way to try more than one version.
		if ( handle is null && library == importLibs[LIBRARY.GSV] )
			handle = pLoadLibrary(importLibs[LIBRARY.GSV1]);

		if ( handle is null )
			throw new Exception("Library load failed ("~ library ~"): "~ 
getErrorMessage());

		loadedLibraries[library] = handle;
	}


	private void* pLoadLibrary(string libraryName, int flag = 
RTLD_NOW)
	{
		void* handle = 
dlopen(cast(char*)toStringz(basePath.buildPath(libraryName)), 
flag | RTLD_GLOBAL);

		if(!handle){
			lastError = dlerror().fromStringz.idup;
		}

		// clear the error buffer
		dlerror();

		return handle;
	}

	private void setDllPath()
	{
		static bool isSet;

		if ( isSet )
			return;

		string gtkPath = getGtkPath();

		if ( gtkPath.length > 0 )
			SetDllDirectoryA((gtkPath~'\0').ptr);

		isSet = true;
	}


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.
Aug 01
parent reply Mike Wey <mike-wey example.com> writes:
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
Aug 01
parent FoxyBrown <Foxy Brown.IPT> writes:
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.
Aug 01
prev sibling parent reply Johnson Jones <JJ Dynomite.com> writes:
So, The error I currently get is

object.Exception generated\gtkd\gtkd\Loader.d(125): Library load 
failed (libgdk-3-0x64.dll):  is not a valid Win32 application.

and libgdk-3-0x64.dll was libgdk-3-0.dll from the 64-bit gtk 
package. (I simply added the extension)... the package downloaded 
from the gdk website.

The size of the file is

1.15 MB (1,211,571 bytes)


What's strange is that the file says the original name was 
libgdk-win32-3.0-0.dll..

This is from the supposedly 64-bit package on the gdk website: 
gtk3-runtime_3.22.4_64-bit

I extracted the files directly from that to compare and that is 
what it says... so, if the dll is truly 32-bit then it would 
explain it and the 64-bit runtime is not correct.

Trying the files from http://www.tarnyko.net/dl/gtk.htm still has 
the same name(maybe the name is not correct... but still doesn't 
work).


I've uninstalled all the gtk stuff and reinstalled using that 
website(seems to be a later version?).

Eventually after setting the paths and all that I run the program 
and get a different error: (note the the spelling error)

object.Error (0): The function you are calling is not pressent in 
your version of GTK+.
----------------
0x00007FF7DBE8A033 in extern (C) void 
gtkd.Loader.Linker.unsupportedSymbol()
0x00007FF7DBAC28BB in gtk.Builder.Builder 
gtk.Builder.Builder.__ctor(immutable(char)[])
0x00007FF7DBAC145A in D main at main.d(17)
0x00007FF7DBEF0172 in 
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x00007FF7DBEF007F in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).tryExec(scope void delegate())
0x00007FF7DBEF010C in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).runAll()
0x00007FF7DBEF007F in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).tryExec(scope void delegate())
0x00007FF7DBEEFF9F in d_run_main
0x00007FF7DBAC1502 in __entrypoint.main
0x00007FF7DBF6B654 in invoke_main at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(65)
0x00007FF7DBF6B567 in __scrt_common_main_seh at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(259)
0x00007FF7DBF6B42E in __scrt_common_main at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(302)
0x00007FF7DBF6B669 in mainCRTStartup at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp(17)
0x00007FFB8EBD2774 in BaseThreadInitThunk
0x00007FFB90050D51 in RtlUserThreadStart


now trying the the gtkd's gtk64.

woot! which works!

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).
Aug 01
parent reply Mike Wey <mike-wey example.com> writes:
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
Aug 02
parent Johnson Jones <JJ Dynomite.com> writes:
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.
Aug 02