Hello, I'm a JavaFX WebKit port maintainer and currently working to merge GTK WebKit 2.24.x(608.1) <https://trac.webkit.org/log/webkit/releases/WebKitGTK/webkit-2.24> to our downstream branch <http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/tip/modules/javafx.web/src/main/native>. I see couple of issues related to Windows 32-bit build, mostly related to recursion tests(js/dom/modules/import-execution-order.html, fast/dom/Document/document-write-recursion.html). It used to work on GTK 2.22.x(607.1) <https://trac.webkit.org/log/webkit/releases/WebKitGTK/webkit-2.22> branch, but it now stopped working. I investigated the issue and I found that it needs more stack space to run. It works when I bump up the stack space to 1MB. I don't see any issues on Linux 32-bit platform. So my question is, do WebKit/JavaScriptCore still supports 32-bit Windows? Thanks & Regards, Arun
On Tue, Jun 25, 2019 at 8:31 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
So my question is, do WebKit/JavaScriptCore still supports 32-bit Windows?
Hi Arunprasad, The last version of WebKitGTK to support Windows was 2.4, from 2014. If you had 2.22 working, that's news to us. To my knowledge, nobody has ever done that before. You might well be the only one; certainly you're the only one to tell us about it. Anyway, that's cool. We don't support Windows anymore because nobody seems to be interested in (a) making it work, and (b) maintaining the code upstream. So you're kinda on your own here. If you only needed a few downstream changes required to make it work, then we could consider accepting those upstream if you'd be willing to maintain the Windows-specific parts. We're not going to be willing to bring back real Windows support otherwise, since all current developers use Linux and are only interested in Linux. Anyway, to answer your question: JavaScriptCore is used on Windows by the Apple Windows port and the WinCairo port, and there is very little GTK-specific code in JSC, so this should be the easiest part of WebKitGTK to get working on Windows. You might consider basing your Windows port on WinCairo rather than WebKitGTK, since that port is designed to run on Windows. Good luck, Michael
Hello Michael, Thanks for your reply. The last version of WebKitGTK to support Windows was 2.4, from 2014.
Sorry for the confusion. Though JavaFX WebKit port is based on GTK stable branches, we don't use any GTK specific bits. We rely on GTK release branches to cherry-pick the stabilisation patches to our downstream branch. Anyway, to answer your question: JavaScriptCore is used on Windows by
the Apple Windows port and the WinCairo port, and there is very little GTK-specific code in JSC, so this should be the easiest part of WebKitGTK to get working on Windows. You might consider basing your Windows port on WinCairo rather than WebKitGTK, since that port is designed to run on Windows.
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that? Thanks & Regards, Arun On Tue, 25 Jun 2019 at 19:59, Michael Catanzaro <mcatanzaro@igalia.com> wrote:
On Tue, Jun 25, 2019 at 8:31 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
So my question is, do WebKit/JavaScriptCore still supports 32-bit Windows?
Hi Arunprasad,
The last version of WebKitGTK to support Windows was 2.4, from 2014.
Sorry f
If you had 2.22 working, that's news to us. To my knowledge, nobody has ever done that before. You might well be the only one; certainly you're the only one to tell us about it. Anyway, that's cool.
We don't support Windows anymore because nobody seems to be interested in (a) making it work, and (b) maintaining the code upstream. So you're kinda on your own here. If you only needed a few downstream changes required to make it work, then we could consider accepting those upstream if you'd be willing to maintain the Windows-specific parts. We're not going to be willing to bring back real Windows support otherwise, since all current developers use Linux and are only interested in Linux.
Anyway, to answer your question: JavaScriptCore is used on Windows by the Apple Windows port and the WinCairo port, and there is very little GTK-specific code in JSC, so this should be the easiest part of WebKitGTK to get working on Windows. You might consider basing your Windows port on WinCairo rather than WebKitGTK, since that port is designed to run on Windows.
Good luck,
Michael
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes. On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC: (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.) I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1). You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try. Maybe the Windows port maintainers know more about the status of 32-bit Windows support? Michael
On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <mcatanzaro@igalia.com> wrote:
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes.
On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC:
(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1).
JIT works on x86 as long as your CPU has support for SSE2 instructions.
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
Option (2) would be using the LLint bytecode interpreter, without JIT. In principle CLoop is expected to work “everywhere” because the interpreter is generated C/C++ code, which gets then built by the same compiler used to build all the rest of WebKit.
Maybe the Windows port maintainers know more about the status of 32-bit Windows support?
Cheers, —Adrián
I was mistaken about one thing (sorry!), please read below... On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro <aperez@igalia.com> wrote:
On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <mcatanzaro@igalia.com> wrote:
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes.
On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC:
(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1).
JIT works on x86 as long as your CPU has support for SSE2 instructions.
Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment. (The JIT compiler does emit SSE2 instructions, though. When/If the JIT is made to work on 32-bit x86, support for SSE2 will be needed.)
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
Option (2) would be using the LLint bytecode interpreter, without JIT.
In principle CLoop is expected to work “everywhere” because the interpreter is generated C/C++ code, which gets then built by the same compiler used to build all the rest of WebKit.
Maybe the Windows port maintainers know more about the status of 32-bit Windows support?
Cheers, —Adrián
On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <aperez@igalia.com> wrote:
I was mistaken about one thing (sorry!), please read below...
On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro <aperez@igalia.com <mailto:aperez@igalia.com>> wrote:
On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <mcatanzaro@igalia.com> wrote:
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes.
On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC:
(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1).
JIT works on x86 as long as your CPU has support for SSE2 instructions.
Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
(The JIT compiler does emit SSE2 instructions, though. When/If the JIT is made to work on 32-bit x86, support for SSE2 will be needed.)
WebKit no longer supports non-SSE2 x86 CPUs even without JIT. https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html <https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html> And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin) is recommended. -Yusuke
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
Option (2) would be using the LLint bytecode interpreter, without JIT.
In principle CLoop is expected to work “everywhere” because the interpreter is generated C/C++ code, which gets then built by the same compiler used to build all the rest of WebKit.
Maybe the Windows port maintainers know more about the status of 32-bit Windows support?
Cheers, —Adrián
webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Thank you all for your guidance. I understand that JIT and LLInt bytecode interpreter is not supported on X86(32-bit). The only option I can use is C_LOOP, which have high stack usage issue in the latest code. I will continue with my investigation on C_LOOP's stack usage. Thanks & Regards, Arun On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki <ysuzuki@apple.com> wrote:
On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <aperez@igalia.com> wrote:
I was mistaken about one thing (sorry!), please read below...
On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro < aperez@igalia.com> wrote:
On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro < mcatanzaro@igalia.com> wrote:
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes.
On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC:
(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1).
JIT works on x86 as long as your CPU has support for SSE2 instructions.
Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
(The JIT compiler does emit SSE2 instructions, though. When/If the JIT is made to work on 32-bit x86, support for SSE2 will be needed.)
WebKit no longer supports non-SSE2 x86 CPUs even without JIT. https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html
And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin) is recommended.
-Yusuke
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
Option (2) would be using the LLint bytecode interpreter, without JIT.
In principle CLoop is expected to work “everywhere” because the interpreter is generated C/C++ code, which gets then built by the same compiler used to build all the rest of WebKit.
Maybe the Windows port maintainers know more about the status of 32-bit Windows support?
Cheers, —Adrián
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Hi Yusuke, I could see that the following comment from https://trac.webkit.org/changeset/245906/webkit,
We also disable this op_wide16 feature in Windows CLoop, which is used in AppleWin port. When the code size of CLoop::execute increases, MSVC starts generating CLoop::execute function with very large stack allocation requirement. Even before introducing this 16bit bytecode, CLoop::execute in AppleWin takes almost 100KB stack height. After introducing this, it becomes 160KB. While the semantics of the function is correctly compiled, such a large stack allocation is not essentially necessary, and this leads to stack overflow errors quite easily, and tests fail with AppleWin port because it starts throwing stack overflow range error in various places. In this patch, for now, we just disable op_wide16 feature for AppleWin so that CLoop::execute takes 100KB stack allocation because this patch is not focusing on fixing AppleWin's CLoop issue. We introduce a new backend type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version of code to reduce the code size of CLoop::execute. In the future, we should investigate whether this MSVC issue is fixed in Visual Studio 2019. Or we should consider always enabling ASM LLInt for Windows.
Does that mean high stack usage in Windows is a known issue? Thanks & Regards, Arun On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Thank you all for your guidance.
I understand that JIT and LLInt bytecode interpreter is not supported on X86(32-bit). The only option I can use is C_LOOP, which have high stack usage issue in the latest code. I will continue with my investigation on C_LOOP's stack usage.
Thanks & Regards, Arun
On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki <ysuzuki@apple.com> wrote:
On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <aperez@igalia.com> wrote:
I was mistaken about one thing (sorry!), please read below...
On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro < aperez@igalia.com> wrote:
On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro < mcatanzaro@igalia.com> wrote:
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes.
On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC:
(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1).
JIT works on x86 as long as your CPU has support for SSE2 instructions.
Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
(The JIT compiler does emit SSE2 instructions, though. When/If the JIT is made to work on 32-bit x86, support for SSE2 will be needed.)
WebKit no longer supports non-SSE2 x86 CPUs even without JIT. https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html
And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin) is recommended.
-Yusuke
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
Option (2) would be using the LLint bytecode interpreter, without JIT.
In principle CLoop is expected to work “everywhere” because the interpreter is generated C/C++ code, which gets then built by the same compiler used to build all the rest of WebKit.
Maybe the Windows port maintainers know more about the status of 32-bit Windows support?
Cheers, —Adrián
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Jun 26, 2019, at 7:57 AM, Arunprasad Rajkumar <ararunprasad@gmail.com> wrote:
Hi Yusuke,
I could see that the following comment from https://trac.webkit.org/changeset/245906/webkit <https://trac.webkit.org/changeset/245906/webkit>,
We also disable this op_wide16 feature in Windows CLoop, which is used in AppleWin port. When the code size of CLoop::execute increases, MSVC starts generating CLoop::execute function with very large stack allocation requirement. Even before introducing this 16bit bytecode, CLoop::execute in AppleWin takes almost 100KB stack height. After introducing this, it becomes 160KB. While the semantics of the function is correctly compiled, such a large stack allocation is not essentially necessary, and this leads to stack overflow errors quite easily, and tests fail with AppleWin port because it starts throwing stack overflow range error in various places. In this patch, for now, we just disable op_wide16 feature for AppleWin so that CLoop::execute takes 100KB stack allocation because this patch is not focusing on fixing AppleWin's CLoop issue. We introduce a new backend type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version of code to reduce the code size of CLoop::execute. In the future, we should investigate whether this MSVC issue is fixed in Visual Studio 2019. Or we should consider always enabling ASM LLInt for Windows.
Does that mean high stack usage in Windows is a known issue?
Yes, I think this is MSVC’s issue. You can try using LLInt ASM for Windows if stack height problem is critical to you now, it would work because WinCairo is using it. But TBH, I’m not sure whether LLInt ASM works on Win32. If the stack height problem is not critical, I strongly recommend using CLoop for now. -Yusuke
Thanks & Regards, Arun
On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar <ararunprasad@gmail.com <mailto:ararunprasad@gmail.com>> wrote: Thank you all for your guidance.
I understand that JIT and LLInt bytecode interpreter is not supported on X86(32-bit). The only option I can use is C_LOOP, which have high stack usage issue in the latest code. I will continue with my investigation on C_LOOP's stack usage.
Thanks & Regards, Arun
On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki <ysuzuki@apple.com <mailto:ysuzuki@apple.com>> wrote:
On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <aperez@igalia.com <mailto:aperez@igalia.com>> wrote:
I was mistaken about one thing (sorry!), please read below...
On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro <aperez@igalia.com <mailto:aperez@igalia.com>> wrote:
On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <mcatanzaro@igalia.com <mailto:mcatanzaro@igalia.com>> wrote:
It's great that you find our stable branches helpful, but keep in mind those branches do not include Windows-specific fixes.
On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar <ararunprasad@gmail.com <mailto:ararunprasad@gmail.com>> wrote:
Right. Actually the problem is in 32-bit Windows platform. I see that the JIT support has been dropped some time ago, and CLOOP based backend seems to be unstable on 32-bit Windows. Any thoughts on that?
So I'm not an expert here, but I understand there are three ways you can build JSC:
(1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?) (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
(-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
I believe that nowadays the only 32-bit platforms supported by JIT are Linux, and there only for ARM and MIPS, not x86. So you're almost certainly going to need to use -DENABLE_JIT=OFF. That eliminates option (1).
JIT works on x86 as long as your CPU has support for SSE2 instructions.
Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
(The JIT compiler does emit SSE2 instructions, though. When/If the JIT is made to work on 32-bit x86, support for SSE2 will be needed.)
WebKit no longer supports non-SSE2 x86 CPUs even without JIT. https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html <https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html>
And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin) is recommended.
-Yusuke
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
Option (2) would be using the LLint bytecode interpreter, without JIT.
In principle CLoop is expected to work “everywhere” because the interpreter is generated C/C++ code, which gets then built by the same compiler used to build all the rest of WebKit.
Maybe the Windows port maintainers know more about the status of 32-bit Windows support?
Cheers, —Adrián
webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
On Tue, Jun 25, 2019 at 10:42 AM, Michael Catanzaro <mcatanzaro@igalia.com> wrote:
You say the cloop seems unstable for you, which is option (3). So perhaps you should try option (2) if you haven't already. I'm not actually sure if that works, because I'm not an expert, which is why I added that (?) to it. But at least it couldn't hurt to try.
I'm being advised that (2) isn't going to work on 32-bit either. So you'll need to try to make cloop work. Good luck... I'm not aware of anybody else supporting JSC on 32-bit Windows. Michael
participants (4)
-
Adrian Perez de Castro
-
Arunprasad Rajkumar
-
Michael Catanzaro
-
Yusuke Suzuki