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/ > bin:/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 ? > > 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.nice@ > gmail.com>: > >>>>> > >>>>> > >>>>> > >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > 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 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > > > >
