<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-12 17:37 GMT+02:00 Henrik Johansen <span dir="ltr"><<a href="mailto:henrik.s.johansen@veloxit.no" target="_blank">henrik.s.johansen@veloxit.no</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 07 Jul 2016, at 12:45 , Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-06 4:04 GMT+02:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi All,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 8:06 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2016-07-05 15:40 GMT+02:00 marcel.taeumel <span dir="ltr"><<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div>
<span></span><div><span>
>><br>
>> --<br>
>> View this message in context:<br>
>> <a href="http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953.html" rel="noreferrer" target="_blank">http://forum.world.st/Poll-Who-is-interested-in-thinking-about-or-already-contributing-to-a-64-bit-OpenSmalltalk-VM-for-Wi-tp4904953.html</a><br>
>> Sent from the Squeak VM mailing list archive at <a href="http://nabble.com" target="_blank">Nabble.com</a>.<br>
>><br>
<br>
</span>Hi Nicolas,<br>
<br></div></blockquote><div> </div><div>Hi Marcel,<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
if we target Cygwin as a build environment, this might be worth noticing:<br>
<a href="https://cygwin.com/faq.html#faq.programming.64bitporting" rel="noreferrer" target="_blank">https://cygwin.com/faq.html#faq.programming.64bitporting</a><br>
<br></blockquote><div><br></div><div>As currently generated, the Spur Vm for 64 bits expects sizeof(long) == 8.<br></div><div>So it is cygwin64 x86_64 compatible, but not so much MSVC... (or mingw-w64 variants...)<br></div><div>IMO, this is the easiest target. then we could inquire about alternate compilers. <br></div></div></div></div></blockquote><div><br></div><div>This is great to hear. So there is a model where sizeof(long) == 8? If that's so, we should target it. There's a /lot/ of work to do if we have to support the Win64 sizeof(long) == 4 model.</div></div></div></div></blockquote><div>snip...<br><br></div><div>After inquiring a bit more, that's not going to be that easy...<br></div><div>Yes, x86_64-pc-cygwin-gcc.exe is LP64 and Spur64 compatible, but it lacks all the interfaces used by platforms/win32 (like _fmode _O_BINARY etc...)<br></div><div>On the other hand, x86_64-w64-mingw32-gcc.exe has all the required win32 interfaces but is thus LLP64.<br><br></div><div>Thus, either we use cygwin, switch to a unix architecture, and loose a bunch of win32 specific features (Direct3D etc...). But how to provide the interface to window manager/GUI?<br></div><div>Or we take the longer path to get VMMaker work on LLP64 (sizeof long == 4, sizeof(long) < sizeof(char *)).<br></div><div><br></div></div>Nicolas<br></div></div>
</div></blockquote></div><br><div>In the interest of making this switch easier, I've looked into setting up a build env on Windows using MSYS2 + mingw-w64 rather than cygwin (which would also mean a substantial upgrade of gcc version for windows builds to 5.4), here's what I've done so far to get a building (but crashing) vm:<div><br></div><div><div>- Download and install MSYS2 (<a href="https://msys2.github.io" target="_blank">https://msys2.github.io</a>)</div><div>- Run update procedure of base system (update-core + exit, followed by repeated pacman -Suu + exit. Might need to make new shortcuts to msys2_shell.cmd -mingw64 / msys2_shell.cmd -mingw32 after all is said and done)</div><div><br></div><div>- Install compiler:</div><div>x86: pacman -S mingw-w64-i686-gcc</div><div>x64: pacman -S mingw-w64-x86_64-gcc (currently unused)</div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes we can do it directly through MSYS+MINGW or load the appropriate MINGW cross compiler packages in CYGWIN64...<br></div><div>I think the cygwin64 setup is easier (see the *.yml files for setting up the bot jobs)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div></div><div>Install tools:</div><div>make: pacman -S make<span style="white-space:pre-wrap"> </span>(yeah, it's needed)</div><div>git: pacman -S git (for updateSCCSVersions)</div><div><br></div><div>Install additional packages used by VM + plugins, for corresponding i686 or x86_64 compiler:</div><div>Haven't determined what's actually needed for a non-crashing build yet.</div><div><br></div><div>copy build.win32x86 to build.win32x86.MSYS2 folder, as new base for modified build.</div><div>I chose to run test .mvm's in squeak.cog.spur target directory, so when that's referenced below, the same changes would be needed in other target dirs as well.</div><div>All "run" steps below in a mingw32 shell; I did however check in mingw64 shell that the combo is LLP on 64-bits.</div><div><br></div></div></div></div></blockquote><div>Yes it's LLP64.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div></div><div>remove cygwin-specific flags removed in new gcc's/ add flags for newer gcc:</div><div>in build.XXXX/common/Makefile and Makefile.plugin, </div><div>remove -mno-cygwin params (removed in GCC 4.something, shouldn't have much affect since we're not using cygwin at all)</div><div>add -mno-stack-arg-probe after -mno-accumulate-outgoing-args (prevents lots of warnings that maccumulate-outgoing-args is needed to probe stack args)</div><div><div>Same flag changes needed to Makefiles in </div><div>platforms\win32\plugins\BochsIA32Plugin</div><div>(should probably be moved to build.XXXX\somewhere if possible, </div><div>or -mno-cygwin made a var like EXPORT below that is easy to change; </div><div>since these files are outside target directory, just removing like I did will affect cygwin builds).</div></div><div><br></div><div>remove -lcrtdll from STDLIBS, (lets MinGW link to msvcrtdll.a only, with both there will be duplicate definition errors)</div><div>comment out line 160, remove comment on 161 in Makefile (aka use EXPORT:=--export-all-symbols)</div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes the makefile are for a really outdated cygwin version (1.4.something).<br></div><div>But you can workaround most problems by passing extra arguments to make (via mvm -- EXTRA-MAKE-ARGS)<br></div><div><br>As long as Eliot use this cygwin config, I hesitate to change anything. It would be necessary to test compatibility of changes with legacy cygwin. But this brand is not distributed anymore. With time machines I succeeded into installing a cygwin 1.5, but it was not functional, so I gave up...<br><br>We ought to convince Eliot that it's time to revise (Hi Eliot ;) ).<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div></div><div>disable SocketPlugin:</div><div>It had some fun issues redefining stuff, dunno if the subsequent removal of crtdll would have fixed things, but for now, I disabled it.</div><div>To do so, some source changes were needed to avoid build failures:</div><div>- add -DNO_NETWORK to DEFS in Makefile (line 146-147)</div><div>- add #ifndef NO_NETWORK guards around</div><div><span style="white-space:pre-wrap"> </span>int win32DebugPrintSocketState(void);</div><div><span style="white-space:pre-wrap"> </span>in platforms\win32\vm\sqWin32Exports.c and platforms\win32\vm\sqWin32Prefs.c</div><div>- remove SocketPlugin from plugins.ext</div><div><br></div></div></div></div></blockquote><div>I think it's better to use winsock 2 (-lws2_32.lib or something like this)<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div></div><div>fix Mpeg3Plugin defining things it assumes is missing on windows, but isn't with mingw64:</div><div>change #if (... || defined(WIN32)) </div><div>before NEEDSTRFUNCS </div><div>in platforms\Cross\plugins\Mpeg3Plugin\libmpeg\changesForSqueak.c</div><div>to #if (... || (defined(WIN32) && !defined( _WIN32 ))) </div><div>(could probably be nicer, however _WIN32 is defined on mingw / microsoft compilers, but not on cygwin platform, so works as distinguisher)</div><div><br></div><div>setup git and update vm versions, so rc compilation doesn't fail:</div><div>git config --global user.email "<a href="mailto:your@email.com" target="_blank">your@email.com</a>"</div><div>git config --global <a href="http://user.name" target="_blank">user.name</a> "John Doe"</div><div>run /scripts/updateSCCSVersions</div><div><br></div><div>configure bochs: </div><div><div>change</div><div>--target=i686-pc-mingw32 \ </div><div>to</div><div>-target=i686-w64-mingw32 \</div><div>in build.win32x86.MSYS2\bochsx86\conf.COG</div><div>then ./conf.COG and ../../processors/IA32/bochs/makeem from that folder</div></div><div><br></div><div>build vm:</div><div>run .mvm -a in build.win32x86.MSYS2 (with -a to build just the assert version, for speeding things up)</div><div><br></div><div>VM will now build, but crash after selecting an image file.</div><div>Time to investigate what additional packages are needed, and/or look at resolving some of the warnings generated during build, there's lots of "implicit definitions" to start from.</div></div><div><br></div><div>Cheers,</div><div>Henry</div></div><div><br></div></div></blockquote><br>Hmm I've produced the 32bits VM with i686-w64-mingw32-gcc on cygwin64, and I think I tested it succesfully, but now you give me a doubt. I have to try again. This is how the travis (appveyor...) artefacts are built.<br><br>On the 64bits side, I've managed to eliminate the warnings about (conversion to/from pointer from/to integer of different size) realted to LLP64, with appropriate changes in VMMaker and platforms files.<br>Still the 64 bits image does not start yet (the VM quits).<br><br><div>Nicolas<br></div></div></div></div>