2017-03-14 22:22 GMT+01:00 Nicolas Cellier <
[email protected]>:

>
>
> 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 <[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/
> 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 <[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