Hi Cyril, The setup-x86.exe -dgnqNO -R "E:\cygwin" -s command was not enough. You must add gcc-core,gcc-g++,binutils,make,libtool,libiconv,automake,autoconf and maybe a few others... The reason is that the build machines come with those packages pre-installed.

On the other hand, I don't remember why we still want to build pkg-config from sources, there is a prebuilt cygwin package if we want. Maybe it's a remnant from the time when mingw was used as build environment?

2018-04-04 1:57 GMT+02:00 Cyril Ferlicot D cyril@ferlicot.me:

Le 04/04/2018 à 00:13, Nicolas Cellier a écrit :

...

Hi Cyril, this is the right list. I'm not sure I can help, it's a bit late. Maybe tomorrow.

I think I found my problem.

Apparently the scripts used a gcc that was installed in 2014 with Haskell Platoform. I removed it and now I have an error about the fact that no compiler was found.

I tried to add cygmin directory to my path but it still fail. At least I know where is the problem now. I'll try to take a look later this week. It begins to be pretty late.

-- Cyril Ferlicot https://ferlicot.fr

Le 04/04/2018 à 20:28, Eliot Miranda a écrit :

Could we add this as a script to {build.win32x86,build.win64x64}/HowToBuild ?  It would be awesome to have an executable fragment that set-up a Windows build machine.  It's a pain in the *ass* setting up cygwin but one gets lots of tools.

Hello Eliot,

When I'll succeed compiling my first vm 32bits on windows I'll try to provide a PR to improve the HowToBuild.

I created an issue to not forget:

https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/237

On Thursday 05 April 2018 10:17 AM, Alistair Grant wrote:

Maybe you're already planning this, but rather than extending the instructions in HowToBuild, can you provide an actual script that does the work, and point to it in HowToBuild? I haven't looked at the windows build, but taking travis and Unix as an example, it could be something like (obviously pseudo-code):

export ARCH=linux64x64 source .travis_install cygwin install ....

Windows build uses .appveyor.yml [1] not travis.

Updating the script to make it work is a one-time effort but will fix it for everyone. README should refer builders to this yml. HowToBuild shouldn't be required at all.

[1] https://www.appveyor.com/docs/ [2] https://www.appveyor.com/docs/appveyor-yml/

Regards .. Subbu

On 05/04/2018 07:36, Nicolas Cellier wrote:

Good idea. Perhaps we should add the preinstalled libraries in .appveyor.yml to begin with.

Then i suspect you get same problem as gcc:     which cmake Don't you have another one installed?

Hi Nicolas,

Executing `which cmake` in my cygwin return:

/cygdrive/c/cygwin/bin/cmake

Which seems correct since I install it on C:\cygwin on this computer.

It looks like the path is not correctly set. I do not understand why, i have concurrent cmake installed and they don't interfere.

Do you launch the build from a cygwin terminal?

If it can help, here is what I do to build the VM:

- I delete my current cygwin folder - I launch the batch to reinstall cygwin (the one I shared in my previous email) to install it in C:\cygwin - I launch the newly installed Cygwin (C:\cygwin\Cygwin.bat) - I execute `export PATH=/cygdrive/c/cygwin/bin:$PATH` to add the newly installed packages to the path. - I move to the pharo.cog.spur folder in cygwin - I launch `./mvm`

Le 08/04/2018 à 12:27, Nicolai Hess a écrit :

Hi Cyril, I am so happy some one got this working (I have the impression, esteban is the only one who can build a windows vm :( )

Hi Nicolai,

Here are my attemps http://forum.world.st/PharoSpur32Vm-tp4930245p4956228.html

I tried to recreate the appveyor environment locally to be able to build the vm, like it is done on the build server. This works fine for the squeak vm, but not for pharo. Whatever I tried, it always fails to build the third-party libs (starting with pkg-config). first, it can not find the proper gcc to use. My cygwin-environment has i686-w64-mingw32-gcc and this is what is set in "Makefile.tools"

TOOLPREFIX:=i686-w64-mingw32-

############################################################################# # C compiler settings (gcc 4.x) # ifeq ($(COMPILER_TO_USE),) COMPILER_TO_USE:=gcc endif

ifeq ($(COMPILER_TO_USE),clang) CC:= $(TOOLPREFIX)clang CXX:= $(TOOLPREFIX)clang++ else CC:= $(TOOLPREFIX)gcc CXX:= $(TOOLPREFIX)g++ endif

so it should set the CC to use i686-w64-mingw32-gcc

but the configure script of pkg-config, complains about "no suitable gcc found"

How did you get this to work ?

I'll explain here the exact step I did. I could compile the win32 bits vm on both windows 7 and windows 10 with the same steps.

1) First I cloned opensmalltalk 2) I downloaded the two intaller of cygwin with git bash with these commands: -- curl -fsSL --retry 4 -m 600 -o "setup-x86.exe" "http://cygwin.com/setup-x86.exe" -- curl -fsSL --retry 4 -m 600 -o "setup-x86_64.exe" "http://cygwin.com/setup-x86_64.exe"

3) I executed the following batch script to install cygwin with all needed dependencies to compile the VM and build the VMMaker image:

--- InstallCygwin.bat --- SET CYG_SETUP=setup-x86.exe SET CYG_ROOT="C:\cygwin" SET CYG_MIRROR=http://cygwin.mirror.constant.com SET MINGW_ARCH=i686

%CYG_SETUP% -dgnqNO -R "%CYG_ROOT%" -s "%CYG_MIRROR%" -l "%CYG_ROOT%\var\cache\setup"^ -P gcc-core^ -P gcc-g++^ -P binutils^ -P libtool^ -P libiconv^ -P automake^ -P autoconf^ -P make^ -P cmake^ -P wget^ -P mingw64-%MINGW_ARCH%-gcc-core^ -P mingw64-%MINGW_ARCH%-gcc-g++^ -P mingw64-%MINGW_ARCH%-headers^ -P mingw64-%MINGW_ARCH%-runtime^ -P zip^ -P mingw64-%MINGW_ARCH%-clang^ -P mingw64-%MINGW_ARCH%-openssl^ -P libiconv-devel^ -P libglib2.0-devel^ -P perl^ -P mingw64-%MINGW_ARCH%-zlib^ -P mingw64-%MINGW_ARCH%-win-iconv^ -P unzip --- InstallCygwin.bat ---

If you copy it, be sure there is spaces before the -P and not tabs. Apparently batch does not like tabs sometimes.

4) Launch cygwin and go to the opensmalltalk-vm/buildwin32x32/pharo.cog.spur/ folder.

And contrary to my previous mail, do NOT add /cygdrive/c/cygwin/bin to the classpath. It caused me the cmake problem.

If I do `which gcc` I get as answer `/usr/bin/gcc`.

Same for mingw-gcc:

JeCisC@JeCisCPC /cygdrive/e/cog/opensmalltalk-vm $ which i686-w64-mingw32-gcc /usr/bin/i686-w64-mingw32-gcc

5) Launch ./mvm and after 1h05 of build I got the vm. (It takes then much less time if I recompile because of the caches)

(If I change the Makefile of pkg-config, to set the CC hardcoded to i686-w64-mingw32-gcc, the configuring works but it fails linking pkg-config, because it can not find libglib-2.0, although this is set in the environment).

There MUST be a way to do this, or how is it done at the biuld-server ? I see the recent windows-builds succeeded, but I can not see where the third-party libs are build.

If i686-w64-mingw32-gcc was not well detected maybe it's because you have another cygwin installed and you don't know it? My first problem was because `Haskell platform` came with a cygwin and this cygwin was the first found in the path.

I hope this can help you.

I am working on a PR to help with the cygwin installation: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242

Le 04/04/2018 à 09:15, Nicolas Cellier a écrit :

Hi Cyril, The setup-x86.exe -dgnqNO -R "E:\cygwin" -s command was not enough. You must add gcc-core,gcc-g++,binutils,make,libtool,libiconv,automake,autoconf and maybe a few others... The reason is that the build machines come with those packages pre-installed.

On the other hand, I don't remember why we still want to build pkg-config from sources, there is a prebuilt cygwin package if we want. Maybe it's a remnant from the time when mingw was used as build environment?

Apparently the ML refuse my mails with an attachment so I resend it without attachment:

Thank you Nicolas,

With your advices I could go further into the build. Now I install cygwin with the batch copied at the end of this mail.

But now I face a new error:

cd builddbg/third-party/libgit2-0.25.1 \ && cmake \

-DCMAKE_TOOLCHAIN_FILE=./Toolchain-cross-mingw32-cygwin.cmake \

-DCMAKE_INSTALL_PREFIX=/cygdrive/e/cog/oscogvm/.thirdparty-cache/windows/i386 \ -DUSE_SSH=ON \ -DBUILD_CLAR=OFF \ -DLIBSSH2_FOUND=ON \

-DLIBSSH2_INCLUDE_DIRS=/cygdrive/e/cog/oscogvm/.thirdparty-cache/windows/i386/include \

-DLIBSSH2_LIBRARIES=/cygdrive/e/cog/oscogvm/.thirdparty-cache/windows/i386/bin/libssh2-1.dll \ -DCMAKE_C_FLAGS="-m32 -static-libgcc -static-libstdc++" \ && make \ && make install CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in /cygdrive/e/cygwin/share/cmake-3.6.2 CMake Error: Error executing cmake::LoadCache(). Aborting.

make[1]: *** [../third-party/Makefile.libgit2:24: /cygdrive/e/cog/oscogvm/.thirdparty-cache/windows/i386/bin/libgit2.dll] Error 1 make[1] : on quitte le répertoire « /cygdrive/e/cog/oscogvm/build.win32x86/pharo.cog.spur » make: *** [../common/Makefile:157: debug] Error 2

Since this is related to libgit2 compilation I guess it only happen in Pharo builds.

I followed an advice from Clement and tried to compile a squeak.cog.spur vm first since there is less plugins to build. But now I face yet another issue.

i686-w64-mingw32-dlltool --input-def Squeak.def.in --output-def build/vm/Squeak.def --output-exp build/vm/Squeak.exp --output-lib build/vm/Squeak.lib build/vm/gcc3x-cointerp.o build/vm/cogit.o build/v m/sqWin32DnsInfo.o build/vm/sqWin32SpurAlloc.o build/vm/sqWin32Directory.o build/vm/sqWin32DirectInput.o build/vm/sqWin32Backtrace.o build/vm/sqWin32Prefs.o build/vm/sqWin32Stubs.o build/vm/sqWin32Ser vice.o build/vm/sqWin32Exports.o build/vm/sqWin32Time.o build/vm/version.o build/vm/sqWin32PluginSupport.o build/vm/sqWin32ExternalPrims.o build/vm/sqWin32VMProfile.o build/vm/sqWin32Main.o build/vm/s qWin32Heartbeat.o build/vm/sqWin32Alloc.o build/vm/sqWin32Window.o build/vm/sqWin32GUID.o build/vm/sqWin32Threads.o build/vm/sqWin32Utils.o build/vm/sqTicker.o build/vm/sqVirtualMachine.o build/vm/sqN amedPrims.o build/vm/sqHeapMap.o build/vm/sqExternalSemaphores.o i686-w64-mingw32-windres --include-dir ../../platforms/win32/misc -D_WIN32 -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING="...\0"' -i Squeak.rc -o build/vm/Squeak.res i686-w64-mingw32-windres: Squeak.rc:7: syntax error make: *** [../common/Makefile:296: Squeak.res] Error 1

This is a build from the commit 0ce1378d23d0423e8cdb5d069f2786ffe884f884 of opensmalltalk-vm.

Do you have any idea what might be the problem with my set-up?

I hope I do not bother you too much with beginners questions.

Have a nice day.

===InstallCygwin.bat===

SET CYG_SETUP=setup-x86.exe SET CYG_ROOT="E:\cygwin" SET CYG_MIRROR=http://cygwin.mirror.constant.com SET MINGW_ARCH=i686

%CYG_SETUP% -dgnqNO -R "%CYG_ROOT%" -s "%CYG_MIRROR%" -l "%CYG_ROOT%\var\cache\setup"^ -P gcc-core^ -P gcc-g++^ -P binutils^ -P libtool^ -P libiconv^ -P automake^ -P autoconf^ -P make^ -P cmake^ -P wget^ -P mingw64-%MINGW_ARCH%-gcc-core^ -P mingw64-%MINGW_ARCH%-gcc-g++^ -P mingw64-%MINGW_ARCH%-headers^ -P mingw64-%MINGW_ARCH%-runtime^ -P zip^ -P mingw64-%MINGW_ARCH%-clang^ -P mingw64-%MINGW_ARCH%-openssl^ -P libiconv-devel^ -P libglib2.0-devel^ -P perl^ -P mingw64-%MINGW_ARCH%-zlib^ -P mingw64-%MINGW_ARCH%-win-iconv

Le 05/04/2018 à 03:09, Eliot Miranda a écrit :

Hi Cyril,

This is not a beginner's question.  Setting up cygwin is hard.  Thank you for your trying this out.  Everyone doing Windows builds, myself included, will be really pleased when this nightmare is documented.  I have been doing it manually for years, meaning I've only done it three times or four times, and it was difficult and frustrating every time.  If this is reduced to a script it will be a good day in vm-land.  Thank you!

Maybe one day; when Windows becomes Unix ;-)

Thanks to the help I got, I could compile the 32bits windows vm for pharo.cog.spur!

I have no idea what was the problem before (the cmake error) since the only thing I changed was to do a pull on oscogvm repository to get to the commit 3421494b43af5611420ebe229b7db3af2064e539.

I tried using it on a recent Pharo 7 image and it worked pretty fine. I just got a message saying the vm it too old but I suppose it must be because during the automatic oscogvm builds some metadata are added are something like that.

Le 05/04/2018 à 22:58, Alistair Grant a écrit :

Hi Cyril,

You need to run scripts/updateSCCSVersions once after checkout. That installs the git hooks to keep the version info up to date.

Ok thank you.

I tried to run it the first time I cloned but it was with an old version of cygwin that I played with some years ago and it ended up in an error.

Now with the clean installation the script ran.

Cheers, Alistair

Hi Ben,

On 6 April 2018 at 06:38, Ben Coman btc@openinworld.com wrote:

On 6 April 2018 at 04:58, Alistair Grant akgrant0710@gmail.com wrote:

...

Hi Cyril,

On 5 April 2018 at 22:54, Cyril Ferlicot D cyril@ferlicot.me wrote:

...

...

I tried using it on a recent Pharo 7 image and it worked pretty fine. I just got a message saying the vm it too old but I suppose it must be because during the automatic oscogvm builds some metadata are added are something like that.

You need to run scripts/updateSCCSVersions once after checkout. That installs the git hooks to keep the version info up to date.

I know this is clearly stated in the README.md, but it seems to catch out many (an me multiple times, duh!)

Someone mentioned adding it as a step to the makefile. That sounds like a good idea.

Right, that was Eliot (from memory).

On the rare occasion I build a windows vm it's in a virtualbox, and updateSCCSVersions is slow, so we'd only want to invoke it if required.

updateSCCSVersions creates three files which are the git hooks to update the version info. I think the absence / presence of those can be used to determine whether to run updateSCCSVersions.

Cheers, Alistair