digitalmars.D.learn - gtk arch issues
- Johnson Jones (17/17) Jul 31 2017 how does one allow both gtk x86 and x64 to work side by side
- Johnson Jones (37/54) Jul 31 2017 I fixed up gtkd so that it uses x86 and x64 versions of dlls but
- Johnson Jones (2/9) Jul 31 2017 Also, why is gtkD even using gtksharp? That's for mono and .net!
- Mike Wey (5/6) Jul 31 2017 We don't. only the (C) Gtk runtime is needed.
- Mike Wey (11/31) Jul 31 2017 At startup GtkD searches the Path for "libgtk-3-0.dll", when it finds
- Johnson Jones (137/171) Jul 31 2017 This is not true(at least completely). I have have a fresh
- Mike Wey (6/11) Aug 01 2017 Gtk also loads some of it's own libraries at start up with GModule /
- Johnson Jones (63/74) Aug 01 2017 Ok, I renamed Program Files (x86)\GtkSharp so that it effectively
- Johnson Jones (44/44) Aug 01 2017 nvm, the file exists. Why it is not being found is unknown.
- Mike Wey (19/35) Aug 01 2017 You renamed the gtk DLL's, i assume you simply renamed them, but to get
- FoxyBrown (33/71) Aug 01 2017 I rebuilt gtkD but obviously not gtk, which I guess was using
- Johnson Jones (68/68) Aug 01 2017 So, The error I currently get is
- Mike Wey (6/24) Aug 02 2017 I currently have 3.22 32bit 3.22 64bit and 2.14 installed side by side
- Johnson Jones (22/47) Aug 02 2017 If you do this you might want to install gtkD and gtk x64 first,
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 2017
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 2017
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:Also, why is gtkD even using gtksharp? That's for mono and .net![...]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 ;/ [...]
Jul 31 2017
Mike Wey <mike-wey example.com> 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 2017
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 2017
On Monday, 31 July 2017 at 20:37:11 UTC, Mike Wey wrote:On 31-07-17 19:16, Johnson Jones wrote: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?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`.
Jul 31 2017
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 2017
On Tuesday, 1 August 2017 at 15:14:50 UTC, Mike Wey wrote:On 01-08-17 01:37, Johnson Jones wrote: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?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.
Aug 01 2017
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 2017
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 2017
On Tuesday, 1 August 2017 at 21:03:44 UTC, Mike Wey wrote:On 01-08-17 22:16, Johnson Jones wrote:I rebuilt gtkD but obviously not gtk, which I guess was using searching the dll's the same way that gtkD did.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.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 2017
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 2017
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 2017
On Wednesday, 2 August 2017 at 14:59:39 UTC, Mike Wey wrote:On 01-08-17 22:50, Johnson Jones wrote: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.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.
Aug 02 2017