+ 1 I'm curious to know the libraries that are making more trouble. (I'm thinking about FreeType) because we should throw away.
Stef On Fri, Mar 17, 2017 at 12:54 AM, Ben Coman <b...@openinworld.com> wrote: > Great to hear this news. > Thanks for your efforts Nicolas. > cheers -ben > > On Fri, Mar 17, 2017 at 4:51 AM, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com> wrote: >> >> >> >> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier >> <nicolas.cellier.aka.n...@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...@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 >>>> >>>> >>> >> >
