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 > 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 > <mailto:philippe.b...@highoctane.be> <philippe.b...@gmail.com > <mailto: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 > <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 > <mailto:nicolaih...@gmail.com>> a écrit : > > > 2017-03-14 22:22 GMT+01:00 Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com > <mailto:nicolas.cellier.aka.n...@gmail.com>>: > > > 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com > <mailto:nicolas.cellier.aka.n...@gmail.com>>: > > > 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com > <mailto:nicolaih...@gmail.com>>: > > > 2017-03-11 10:01 GMT+01:00 Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com > <mailto: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 > <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 > <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 > <mailto: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 > <mailto:nicolaih...@gmail.com>>: > > > 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com > <mailto:nicolaih...@gmail.com>>: > > > 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@gmail.com>>: > >> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com >> <mailto:nicolaih...@gmail.com>> wrote: >> >> >> >> 2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clem...@gmail.com >> <mailto: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 > <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 >> <mailto: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/ >> <http://files.pharo.org/vm/pharo-spur32/linux/> >> >> The latest builds on the buildserver are from the last year only. >> >> nicolai
