Hi Nicolai,
> On Jul 22, 2017, at 6:03 AM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > 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", There isn't a configure script. The choice of which compiler to make, flags to use etc is made in build.win32x86/common/Makefile.rules build.win32x86/common/Makefile.tools and should be able to be overridden by editing build.win32x86/pharo.cog.spur/Makefile > > 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-project/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/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>>> >>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/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/opensmalltalk-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-constructors.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 >>>>>>>>>>>>>> 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\LoadVMMaker.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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >
