Re: gtk arch issues(fixed)
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.
Re: gtk arch issues(fixed)
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
Re: gtk arch issues
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.
Re: gtk arch issues
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
Re: gtk arch issues(fixed)
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+. 0x7FF7DBE8A033 in extern (C) void gtkd.Loader.Linker.unsupportedSymbol() 0x7FF7DBAC28BB in gtk.Builder.Builder gtk.Builder.Builder.__ctor(immutable(char)[]) 0x7FF7DBAC145A in D main at main.d(17) 0x7FF7DBEF0172 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 0x7FF7DBEF007F in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) 0x7FF7DBEF010C in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() 0x7FF7DBEF007F in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) 0x7FF7DBEEFF9F in d_run_main 0x7FF7DBAC1502 in __entrypoint.main 0x7FF7DBF6B654 in invoke_main at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(65) 0x7FF7DBF6B567 in __scrt_common_main_seh at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(259) 0x7FF7DBF6B42E in __scrt_common_main at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(302) 0x7FF7DBF6B669 in mainCRTStartup at f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp(17) 0x7FFB8EBD2774 in BaseThreadInitThunk 0x7FFB90050D51 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).
Re: gtk arch issues
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.
Re: gtk arch issues
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?
Re: gtk arch issues
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
Re: gtk arch issues
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_6dad63fefc436da8\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:
Re: gtk arch issues
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
Re: gtk arch issues
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
Re: gtk arch issues
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!
Re: gtk arch issues
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 ;/
gtk arch issues
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).
