Definitely interested in this! On Thu, Mar 16, 2017 at 9:51 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote:
> > > 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>: >> >>> sorry for coming late to this thread… hard week :) >>> why we are trying to compile with cygwin? >>> is there a problem with the mingw distro? >>> >>> I didn’t have the time to update the README, sadly. But well… following >>> appveyor configuration should give you all you need to reproduce the build >>> (that’s what I did last time I built an environment). >>> >>> Esteban >>> >>> >>> Hi Esteban, >> How did you solve the directx problem? >> >> > > Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using > cross-compiler i686-w64-mingw32 > (cygwin64 here but it could be cygwin32). > > This is good news, because it means that: > - we don't have to rely anymore on non-redistributable legacy directx SDK > - we can compile with clang if we want too (well, for all the 3rd party > dependencies, that's a bit more work) > - it opens the door to win64 version > > Some details remain: I have to pick the right libgcc and libwindpthread as > weel as iconv.dll and copy them to the pharo build directory to satisfy the > SDL2 dependencies. > Maybe there's a better option for compiling SDL2 with more static stuff? > -static-libgcc or something... > > cairo required another dirty hack, not the one of Igor which must be > eliminated for cygwin compilation, but one for working around the files > that are not truncated when overwritten... > I wonder where this bug comes from? make? cygwin itself? VirtualBox > (unlikely)? > > If I find the energy to rebase -i and clean a bit my non linear attempts > (squash/reorder/...) then I'll push the branch on opensmalltalk-vm and see > how appveyor like it. > > > > >> On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaih...@gmail.com> wrote: >>> >>> >>> >>> 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 >>>>> i...@gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>>> i...@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 >>>>>>>> i...@gmail.com>: >>>>>>>> >>>>>>>>> Hi Nicolai, >>>>>>>>> >>>>>>>>> If you look at appveyor.yml configuration on >>>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Co >>>>>>>>> g/.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-pr >>>>>>>>> oject/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-cach >>>>>> e/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/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-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 >>>>>>>>>>>>>> <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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >> >