• Benjamin Thaut (9/9) Nov 07 2013 I'm wondering what's the correct way to handle multiple gtk
• Jacob Carlborg (5/11) Nov 07 2013 One way to solve it would be to have the Gtk dll in the same directory
• Benjamin Thaut (6/16) Nov 07 2013 Woudln't it be necessary to copy the other gtk assets there too? Like
• Alexandr Druzhinin (3/18) Nov 07 2013 I have multiple installations and handle them using .cmd files that set
• Alexandr Druzhinin (8/28) Nov 07 2013 So if I have gtk binary installed to two path: c:\gtk32 and c:\gtk64 I d...
• Benjamin Thaut (7/37) Nov 07 2013 I'm wondering how other gtk apps do this. Because this must somehow be
• Mike Wey (9/47) Nov 07 2013 I don't know how other apps do this, but afaik giving each app there own...
• Benjamin Thaut (9/16) Nov 07 2013 By "in memory" you mean already loaded into the memory of the currently
• Mike Wey (6/21) Nov 07 2013 I would say globally, i vaguely remember having a strange issue because
• Jacob Carlborg (6/8) Nov 07 2013 I have no idea. Just give it a try and copy the DLL's. In any case,
• Mike Wey (8/14) Nov 07 2013 Having both the 32 and 64 bits versions of GTK in your PATH doesn't seem...
• Benjamin Thaut (7/10) Nov 07 2013 Well it is for me. As the dlls are named the same the 64-bit executable
• Jacob Carlborg (4/7) Nov 07 2013 No flag available for ignoring DLL's of the wrong architecture?

Benjamin Thaut <code benjamin-thaut.de> writes:

I'm wondering what's the correct way to handle multiple gtk 
installations on windows? When developing I most likely will have at 
least two at all times, the 32-bit version and the 64-bit version.
When they are both added to the PATH they will obviously conflict.

Googeling this issue doesn't help much because of the double meaning of 
"Windows".
-- 
Kind Regards
Benjamin Thaut

Jacob Carlborg <doob me.com> writes:

On 2013-11-07 11:45, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double meaning of
 "Windows".

One way to solve it would be to have the Gtk dll in the same directory 
as the executable. Windows will look there first, if I recall correctly.

-- 
/Jacob Carlborg

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 07.11.2013 15:58, schrieb Jacob Carlborg:
 On 2013-11-07 11:45, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double meaning of
 "Windows".

 One way to solve it would be to have the Gtk dll in the same directory
 as the executable. Windows will look there first, if I recall correctly.

Woudln't it be necessary to copy the other gtk assets there too? Like 
the fonts etc?

-- 
Kind Regards
Benjamin Thaut

Alexandr Druzhinin <drug2004 bk.ru> writes:

07.11.2013 22:12, Benjamin Thaut пишет:
 Am 07.11.2013 15:58, schrieb Jacob Carlborg:
 On 2013-11-07 11:45, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double meaning of
 "Windows".

 One way to solve it would be to have the Gtk dll in the same directory
 as the executable. Windows will look there first, if I recall correctly.

 Woudln't it be necessary to copy the other gtk assets there too? Like
 the fonts etc?

I have multiple installations and handle them using .cmd files that set 
path for specific installation. I like command line interface. :)

Alexandr Druzhinin <drug2004 bk.ru> writes:

07.11.2013 22:53, Alexandr Druzhinin пишет:
 07.11.2013 22:12, Benjamin Thaut пишет:
 Am 07.11.2013 15:58, schrieb Jacob Carlborg:
 On 2013-11-07 11:45, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double meaning of
 "Windows".

 One way to solve it would be to have the Gtk dll in the same directory
 as the executable. Windows will look there first, if I recall correctly.

 Woudln't it be necessary to copy the other gtk assets there too? Like
 the fonts etc?

 I have multiple installations and handle them using .cmd files that set
 path for specific installation. I like command line interface. :)

So if I have gtk binary installed to two path: c:\gtk32 and c:\gtk64 I do:
path=c:\gtk32:%path%
for using gtk32 installation and do:
path=c:\gtk64:%path%
for using gtk64. But now I use linux and may forget about some details. 
I remember that dll hell very possible but it's not the problem if set 
path correctly.

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 07.11.2013 16:58, schrieb Alexandr Druzhinin:
 07.11.2013 22:53, Alexandr Druzhinin пишет:
 07.11.2013 22:12, Benjamin Thaut пишет:
 Am 07.11.2013 15:58, schrieb Jacob Carlborg:
 On 2013-11-07 11:45, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double
 meaning of
 "Windows".

 One way to solve it would be to have the Gtk dll in the same directory
 as the executable. Windows will look there first, if I recall
 correctly.

 Woudln't it be necessary to copy the other gtk assets there too? Like
 the fonts etc?

 I have multiple installations and handle them using .cmd files that set
 path for specific installation. I like command line interface. :)

 So if I have gtk binary installed to two path: c:\gtk32 and c:\gtk64 I do:
 path=c:\gtk32:%path%
 for using gtk32 installation and do:
 path=c:\gtk64:%path%
 for using gtk64. But now I use linux and may forget about some details.
 I remember that dll hell very possible but it's not the problem if set
 path correctly.

I'm wondering how other gtk apps do this. Because this must somehow be 
possible without the user modifing the PATH. Pidgin for example installs 
the gtk runtime and then somehow magically always uses this runtime, no 
matter whats inside the path.

Kind Regards
Benjamin Thaut

Mike Wey <mike-wey example.com> writes:

On 11/07/2013 06:16 PM, Benjamin Thaut wrote:
 Am 07.11.2013 16:58, schrieb Alexandr Druzhinin:
 07.11.2013 22:53, Alexandr Druzhinin пишет:
 07.11.2013 22:12, Benjamin Thaut пишет:
 Am 07.11.2013 15:58, schrieb Jacob Carlborg:
 On 2013-11-07 11:45, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double
 meaning of
 "Windows".

 One way to solve it would be to have the Gtk dll in the same directory
 as the executable. Windows will look there first, if I recall
 correctly.

 Woudln't it be necessary to copy the other gtk assets there too? Like
 the fonts etc?

 I have multiple installations and handle them using .cmd files that set
 path for specific installation. I like command line interface. :)

 So if I have gtk binary installed to two path: c:\gtk32 and c:\gtk64 I
 do:
 path=c:\gtk32:%path%
 for using gtk32 installation and do:
 path=c:\gtk64:%path%
 for using gtk64. But now I use linux and may forget about some details.
 I remember that dll hell very possible but it's not the problem if set
 path correctly.

 I'm wondering how other gtk apps do this. Because this must somehow be
 possible without the user modifing the PATH. Pidgin for example installs
 the gtk runtime and then somehow magically always uses this runtime, no
 matter whats inside the path.

 Kind Regards
 Benjamin Thaut

I don't know how other apps do this, but afaik giving each app there own 
private copy can still cause problems.
If a dll with the same name as the one you are trying to load is already 
in memory, Windows will use the the one already in memory.
When the version thats in memory is to old for the app you are starting 
it will crash because of the version mismatch.

-- 
Mike Wey

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 07.11.2013 20:28, schrieb Mike Wey:
 On 11/07/2013 06:16 PM, Benjamin Thaut wrote:

 I don't know how other apps do this, but afaik giving each app there own
 private copy can still cause problems.
 If a dll with the same name as the one you are trying to load is already
 in memory, Windows will use the the one already in memory.
 When the version thats in memory is to old for the app you are starting
 it will crash because of the version mismatch.

By "in memory" you mean already loaded into the memory of the currently 
running process?

Because all the process of my system use so many different versions of 
zlib1.dll that the entire thing would explode right in my face if that 
statement would apply globally.

-- 
Kind Regards
Benjamin Thaut

Mike Wey <mike-wey example.com> writes:

On 11/07/2013 09:02 PM, Benjamin Thaut wrote:
 Am 07.11.2013 20:28, schrieb Mike Wey:
 On 11/07/2013 06:16 PM, Benjamin Thaut wrote:

 I don't know how other apps do this, but afaik giving each app there own
 private copy can still cause problems.
 If a dll with the same name as the one you are trying to load is already
 in memory, Windows will use the the one already in memory.
 When the version thats in memory is to old for the app you are starting
 it will crash because of the version mismatch.

 By "in memory" you mean already loaded into the memory of the currently
 running process?

I would say globally, i vaguely remember having a strange issue because 
of it years ago. But i can be completely wrong about that.

The MDSN docs just say: "in memory" and don't specify anything beyond that.

 Because all the process of my system use so many different versions of
 zlib1.dll that the entire thing would explode right in my face if that
 statement would apply globally.

-- 
Mike Wey

Jacob Carlborg <doob me.com> writes:

On 2013-11-07 16:12, Benjamin Thaut wrote:

 Woudln't it be necessary to copy the other gtk assets there too? Like
 the fonts etc?

I have no idea. Just give it a try and copy the DLL's. In any case, 
wouldn't the assets be the same for 32 and 64bit if they are the same 
version.

-- 
/Jacob Carlborg

Mike Wey <mike-wey example.com> writes:

On 11/07/2013 11:45 AM, Benjamin Thaut wrote:
 I'm wondering what's the correct way to handle multiple gtk
 installations on windows? When developing I most likely will have at
 least two at all times, the 32-bit version and the 64-bit version.
 When they are both added to the PATH they will obviously conflict.

 Googeling this issue doesn't help much because of the double meaning of
 "Windows".

Having both the 32 and 64 bits versions of GTK in your PATH doesn't seem 
to be causing any problems for me.

What can be a problem is installing different versions side by side, say 
both GTK 3.x and GTK 2.x, in that case the newer version should be in 
the path before the older version.

-- 
Mike Wey

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 07.11.2013 20:15, schrieb Mike Wey:
 On 11/07/2013 11:45 AM, Benjamin Thaut wrote:

 Having both the 32 and 64 bits versions of GTK in your PATH doesn't seem
 to be causing any problems for me.

Well it is for me. As the dlls are named the same the 64-bit executable 
attempts to load the 32-bit dll first (because its the first one to be 
found in the PATH)

-- 
Kind Regards
Benjamin Thaut

Jacob Carlborg <doob me.com> writes:

On 2013-11-07 21:03, Benjamin Thaut wrote:

 Well it is for me. As the dlls are named the same the 64-bit executable
 attempts to load the 32-bit dll first (because its the first one to be
 found in the PATH)

No flag available for ignoring DLL's of the wrong architecture?

-- 
/Jacob Carlborg