Hm, I tried to create the build environment used for the windows vm build from opensmalltalk.
I setup a cygwin environment with the same install commands as from https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml My problems, first it is missing make and wget, I can add make and wget to the install command line for cygwin, but I am curious why it is working on the build server ? Anyway, after I got this working, the build stops and building the pkg-config package. The log says it can not find a gcc, I know that the build process with cygwin uses i686-w64-mingw32-gcc or x86_64-w64-mingw32-gcc But I don't understand where is the missing step to tell the configure scripts to use the i686-w64-mingw32-gcc command instead of "gcc", again, this seems to work on the appveyor build but not locally on my machine. Any idea what I had missed? nicolai 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: > > > 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be < > philippe.b...@gmail.com>: > >> I made my own build here. >> Not up to date with latest stuff but should work for the build process. >> >> https://ci.appveyor.com/project/philippeback/pharo-vm >> >> It uses my forked repo and provided you set your own bintray env vars for >> API keys will publish there. >> >> Check all of the output of env vars and where/which in the appveyor >> console to see what gets used when when it comes to compilers and so on as >> there were various compiler versions involved at one point. >> >> Third party cache part is also worth checking. >> >> Still not able to build on my local box at the moment due to some tools >> discrepancies happening. >> >> My build artifacts are embarking too much at this point but allow you ro >> get the release, debug, and assert vms for windows. This helps when >> debugging as backtraces and so on are much more meaningful and one can use >> gdb more effectively to understand what is going on. >> >> Just keep the dlls and exes and you'll be fine. >> > > Ah good, thank you. > > > >> >> HTH >> >> Phil >> >> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit : >> >>> >>> >>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.n...@gmail.com>: >>> >>>> >>>> >>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.n...@gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier < >>>>>> nicolas.cellier.aka.n...@gmail.com>: >>>>>> >>>>>>> Hi Nicolai, >>>>>>> >>>>>>> If you look at appveyor.yml configuration on >>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/. >>>>>>> appveyor.yml, you will see that the pharo brand is not yet in the >>>>>>> matrix. >>>>>>> >>>>>>> It's because builds are based on cygwin, but as I understood, some >>>>>>> library used by some plugin required by pharo refuse to compile with >>>>>>> cygwin. They appear to work with mingw32. >>>>>>> Cygwin provides headers for legacy directx, some distribution of >>>>>>> mingw32 did in the past, but it does not seem the case anymore. >>>>>>> Using the directx headers from Microsoft SDK is a problem. They are >>>>>>> not redistributable and can't be found anymore on the net (too old). We >>>>>>> cannot seriously base the builds on something so fragile (both >>>>>>> technically >>>>>>> and legally) in the long term. >>>>>>> >>>>>>> Also, the 64 bits VM does only work with clang, and we don't have >>>>>>> anything available as a 64bits Microsoft SDK... So pharo has to fix that >>>>>>> too. >>>>>>> >>>>>>> In the interim, you should look at https://github.com/pharo-proje >>>>>>> ct/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. >>>>>>> >>>>>> >>>>>> Ok, thank you. >>>>>> >>>>>> >>>>> >>>>> I gave it a shot on sunday, because it was particularly rainy in >>>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>>> cygwin. >>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>>>> forget a few other niceties that some not so well informed programmers >>>>> committed with the faith that it would make their life "easier". It >>>>> certainly does not make mine simpler... >>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it >>>>> seems that the workaround of Igor does not work anymore. >>>>> ssize_t, WTF??? >>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll >>>>> publish the branch to see how far appveyor goes. >>>>> >>>>> >>>>> >>>> >>>> So I solved the ssize_t problem by removing the hack from Igor which is >>>> not necessary anymore... >>>> But got another problem soon after while building the tests... >>>> There are trailing lines generated at end of >>>> tests/cairo-test-constructors.c that make the compilation fail: >>>> >>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensm >>>> alltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/w >>>> indows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations >>>> -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings >>>> -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute >>>> -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self >>>> -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c >>>> -o cairo_test_suite-cairo-test-constructors.o `test -f >>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>> cairo-test-constructors.c:1118:1: attention : la définition de données >>>> n'a pas de type ni de classe de stockage >>>> oning (); >>>> ^ >>>> cairo-test-constructors.c:1118:1: attention : type defaults to ‘int’ >>>> in declaration of ‘oning’ [-Wimplicit-int] >>>> cairo-test-constructors.c:1119:5: attention : la définition de données >>>> n'a pas de type ni de classe de stockage >>>> _register_ft_show_glyphs_table (); >>>> ^ >>>> >>>> And the file looks like it has obviously been overwritten, but not >>>> truncated !!! >>>> >>>> ... >>>> extern void _register_multi_page (void); >>>> extern void _register_fallback_resolution (void); >>>> >>>> void >>>> _cairo_test_runner_register_tests (void) >>>> { >>>> _register_a1_bug (); >>>> _register_a1_clip_paint (); >>>> ... >>>> _register_multi_page (); >>>> _register_fallback_resolution (); >>>> } >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *oning (); _register_ft_show_glyphs_table (); >>>> _register_ft_text_vertical_layout_type1 (); >>>> _register_ft_text_vertical_layout_type3 (); >>>> _register_ft_text_antialias_none (); _register_ps_eps (); >>>> _register_ps_features (); _register_ps_surface_source (); >>>> _register_svg_surface (); _register_svg_clip (); >>>> _register_svg_surface_source (); _register_multi_page (); >>>> _register_fallback_resolution ();}* >>>> >>>> This file is generated by a shell script test/make-cairo-test-construct >>>> ors.sh >>>> I can't find any reference of the bug, and upgrade to version 1.14.8 >>>> does not solve the issue. >>>> So it will wait until tomorrow... >>>> >>> >>> >>> I got the build for windows with mingw nearly working. (it can not build >>> some plugins, like SqueakSSL for windows, because the used wincrypt.h is >>> different in the mingw distrubtion). >>> >>> I still have the problem, that there seems to be a preprocessing step , >>> that should put the vm-version (and source timestamp) in the >>> *sqSCCSVersion.h* >>> I got this working by running .travis_build.sh (with the options for >>> arch/flavor/platform) But how is this done normally when you build a vm >>> locally? >>> And how is this done for the pharo-vm we currently use? >>> >>> >>> >>>> >>>> Nicolas >>>> >>>> >>>>>>> I hope that Esteban will find time to resolve all these problems and >>>>>>> have pharo brand back on opensmalltalk-vm. I guess that any form of >>>>>>> help is >>>>>>> welcome. >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> >>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: >>>>>>> >>>>>>>> I still have problems building a vm on windows. >>>>>>>> can you give me some hints how to start ? >>>>>>>> I cloned the recent pharo-vm project, >>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>> run >>>>>>>> mvm >>>>>>>> >>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>>>>>>> found, I had to adjust the include path for finding directx header, >>>>>>>> missing >>>>>>>> variable replacement for git-versions). >>>>>>>> So I may miss some important steps. >>>>>>>> Is there a repository where I can clone the mingw environment used >>>>>>>> to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Nicolai >>>>>>>> >>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com> >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com> >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I believe they're built from* https://github.com/OpenSmalltalk/vm >>>>>>>>>>>> <https://github.com/OpenSmalltalk/vm>* using travis and >>>>>>>>>>>> appveyor. On the gitbhub readme there are relevant links. All built >>>>>>>>>>>> artifacts are also kept on bintray for history. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> no, they aren’t :) >>>>>>>>>>> instead, they are built here: https://github.com/pharo >>>>>>>>>>> -project/pharo-vm >>>>>>>>>>> >>>>>>>>>>> (README still not updated) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>>>>>>>> anymore (something wrong with generating the generator.image, I'll >>>>>>>>>> now >>>>>>>>>> reset my local pharo-vm build directory and see if it works >>>>>>>>>> afterwards). >>>>>>>>>> >>>>>>>>> >>>>>>>>> see attached the stderr log : >>>>>>>>> >>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>>>>>>>> dVMMaker.st' >>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>> >>>>>>>>> .... >>>>>>>>> >>>>>>>>> >>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>>>>>>>> master ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Esteban >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>>>>>>>>>>> nicolaih...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>> I don't see them on the build server, only the buildresults at >>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>> >>>>>>>>>>>>> The latest builds on the buildserver are from the last year >>>>>>>>>>>>> only. >>>>>>>>>>>>> >>>>>>>>>>>>> nicolai >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >
