2017-03-15 9:22 GMT+01:00 [email protected] <
[email protected]>:

> 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" <[email protected]> a écrit :
>
>>
>>
>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai
>> l.com>:
>>
>>>
>>>
>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai
>>> l.com>:
>>>
>>>>
>>>>
>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <[email protected]>:
>>>>
>>>>>
>>>>>
>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <
>>>>> [email protected]>:
>>>>>
>>>>>> 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-proje
>>>>>> ct/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-cache/w
>>> indows/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-construct
>>> ors.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 <[email protected]>:
>>>>>>
>>>>>>> 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 <[email protected]>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <[email protected]>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <[email protected]>:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 Clément Bera <[email protected]>:
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> [email protected]> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Reply via email to