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.nice@gmai >> l.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/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... 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
