2017-07-23 23:18 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: > > > 2017-07-23 22:38 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: >> >>> >>> >>> 2017-07-23 19:42 GMT+02:00 Hernán Morales Durand < >>> hernan.mora...@gmail.com>: >>> >>>> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaih...@gmail.com>: >>>> > >>>> > 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", >>>> > >>>> > again, this seems to work on the appveyor build but not locally on my >>>> machine. >>>> > >>>> > Any idea what I had missed? >>>> > >>>> >>>> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in >>>> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and >>>> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the >>>> line: >>>> >>>> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" >>>> >>>> to >>>> >>>> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bi >>>> n:/usr/bin:/bin" >>>> >>>> And finally >>>> >>>> source /etc/profile >>>> >>>> Cheers, >>>> >>> >>> I always had problems using mingw in the past. I got a working mingw >>> environment some years ago, and a newer mingw version >>> did not work well (some changes on the debug and exception format). >>> But now, the build process for pharo did change. (The build instructions >>> on github/pharo-vm are old and do not work anymore. >>> >>> And I hoped to get a more automatic and more reliable build process by >>> using the same commands used by the build server for >>> the opensmalltalk pharo vm sources. >>> >>> And I thought the compiler used to build the latest pharo-vm for windows >>> is from cygwin ? >>> >>> >>> >> Hi Nicolai, >> more exactly we cross compile from a cygwin environment for a mingw >> target. >> The main reason for switching to cygwin are: >> - this is required for the 64 bit vm >> - the other flavours on opensmallalk (squeak/newspeak) were also built >> with cygwin, so it's more simple to maintain a single way of doing things >> >> Cygwin is required for the 64bits vm because of directx. >> Indeed cygwin still provides support for the legacy directx version used >> by the VM, while recent mingw does not. >> Until we port to a newer API, mingw thus depends on the MS directx >> include and library files that we redistribute for 32 bits only (and we >> should not without permission, I plan to remove these files). That does not >> work at all for 64 bits. >> >> The 64bits VM does not work either with gcc and requires clang currently. >> installing clang in mingw is tedious, while it's a prebuilt package in >> cygwin. >> >> You now know why we use cygwin, not how, maybe it does not terribly >> helps, but it's important in order to avoid regression, or to be aware of >> what need to be done before changing the building environment again... >> Could you detail what you tried exactly? >> > > > Setup cygwin: > > CYG_MIRROR=http://cygwin.mirror.constant.com > CYG_ROOT='c:\cygwin' > CYG_SETUP=setup-x86.exe > MINGW_ARCH=i686 > $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l > "$CYG_ROOT"/var/cache/setup -P mingw64-$MINGW_ARCH-gcc-core, > mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers, > mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang, > libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_ > ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget > > (taken from the appveyor.xml, I needed to add make and wget, don't know > why, from the appveyor log I see that make and wget is installed, even > without this option...) > > Run the build (from an "empty" environment, that is, no other msys or > mingw in the path environment variable) > > set FLAVOR=pharo.cog.spur > set ARCH=win32x86 > set MINGW_ARCH=i686 > set CYG_ROOT=c:\cygwin > set TRAVIS_OS_NAME=windows > set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%; > git config --system core.autocrlf input > git clone -q --depth=5 --branch=Cog https://github.com/ > OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm > SET APPVEYOR_BUILD_FOLDER=c:\projects\vm > git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16 > %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0</dev/null;exec > ./.travis_build.sh" > > I still have problems building the pharo vm locally with the above setup. Somehow I can not build the thirdparty libs The compiler I use from the cygwin installation is i686-w64-mingw32-gcc But I can not see where this is set for the third party libs (starting with pkg-config).
Are they really build on the travis build server ? I can not see it in the build log. nicolai > > > >> >> Nicolas >> >> >>>> Hernán >>>> >>>> > >>>> > 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/opens >>>> malltalk-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/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 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 >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>> >>>> >> >>>> > >>>> >>>> >>> >> >
