[Vm-dev] [Pharo-dev] PharoSpur32Vm

Eliot Miranda eliot.miranda at gmail.com
Fri Mar 17 00:55:29 UTC 2017


On Thu, Mar 16, 2017 at 1:51 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm at 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
>

Bravo Nicolas!  Are you planning to make this the default build, updating
HowToBuild?  It would be great to ditch the ancient gcc 3.x build.


>
> 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 <nicolaihess at gmail.com> wrote:
>>>
>>>
>>>
>>> 2017-03-15 9:22 GMT+01:00 philippe.back at highoctane.be <
>>> philippe.back at 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" <nicolaihess at gmail.com> a écrit :
>>>>
>>>>>
>>>>>
>>>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n
>>>>> ice at gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n
>>>>>> ice at gmail.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n
>>>>>>>> ice at gmail.com>:
>>>>>>>>
>>>>>>>>> Hi Nicolai,
>>>>>>>>>
>>>>>>>>> If you look at appveyor.yml configuration on
>>>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Co
>>>>>>>>> g/.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-pr
>>>>>>>>> oject/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/opensm
>>>>>> alltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1
>>>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cach
>>>>>> e/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 <nicolaihess at 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 <nicolaihess at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <
>>>>>>>>>>>> estebanlm at gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 Clément Bera <
>>>>>>>>>>>>> bera.clement at 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 <
>>>>>>>>>>>>>> nicolaihess at 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>
>>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170316/69bd098d/attachment-0001.html>


More information about the Vm-dev mailing list