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
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. On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess@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
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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!
On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess@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
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@gmail.com <mailto:bera.clement@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 <https://github.com/pharo-project/pharo-vm> (README still not updated) Esteban
On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@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/ <http://files.pharo.org/vm/pharo-spur32/linux/>
The latest builds on the buildserver are from the last year only.
nicolai
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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). 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@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
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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\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 <nicolaihess@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
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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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\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 <nicolaihess@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
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. 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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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\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 <nicolaihess@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
2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@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 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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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\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 <nicolaihess@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
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ 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-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.
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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.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-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... 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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
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. HTH Phil Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess@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@gmai l.com>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@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-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/ 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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@gmail.com> 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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
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
On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be <mailto:philippe.back@highoctane.be> <philippe.back@gmail.com <mailto:philippe.back@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 <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@gmail.com <mailto:nicolaihess@gmail.com>> a écrit :
2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>:
2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: Hi Nicolai,
If you look at appveyor.yml configuration on https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml <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 <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 <nicolaihess@gmail.com <mailto:nicolaihess@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@gmail.com <mailto:nicolaihess@gmail.com>>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@gmail.com <mailto:bera.clement@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 <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 <nicolaihess@gmail.com <mailto:nicolaihess@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/ <http://files.pharo.org/vm/pharo-spur32/linux/>
The latest builds on the buildserver are from the last year only.
nicolai
2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm@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?
On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be <philippe.back@ 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@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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka. nice@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/opensm alltalk-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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com> :
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
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@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 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@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@gmail.com> a écrit :
2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@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-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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com
:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
Great to hear this news. Thanks for your efforts Nicolas. cheers -ben On Fri, Mar 17, 2017 at 4:51 AM, Nicolas Cellier < nicolas.cellier.aka.nice@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@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
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@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@gmail.com> a écrit :
2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera < bera.clement@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@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
+ 1 I'm curious to know the libraries that are making more trouble. (I'm thinking about FreeType) because we should throw away. Stef On Fri, Mar 17, 2017 at 12:54 AM, Ben Coman <btc@openinworld.com> wrote:
Great to hear this news. Thanks for your efforts Nicolas. cheers -ben
On Fri, Mar 17, 2017 at 4:51 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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@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
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@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be <philippe.back@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@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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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 <nicolaihess@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
On Thu, Mar 16, 2017 at 1:51 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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@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@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@gmail.com> a écrit :
2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera < bera.clement@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@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
Definitely interested in this! On Thu, Mar 16, 2017 at 9:51 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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@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
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@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@gmail.com> a écrit :
2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera < bera.clement@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@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
2017-03-16 21:51 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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@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
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)?
what hack from Igor ? I thought the pharo build just downloads a tar.gz archive from cairo and starts the configure/build ?
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@gmail.com> wrote:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@gmail.com> a écrit :
2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@gmail.com>:
2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n ice@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@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera < bera.clement@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@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
2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-16 21:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:
2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:
2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm@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
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)?
what hack from Igor ? I thought the pharo build just downloads a tar.gz archive from cairo and starts the configure/build ?
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d3c98eaa001d2d07c...
2017-03-17 23:40 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-16 21:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai l.com>:
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@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
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)?
what hack from Igor ? I thought the pharo build just downloads a tar.gz archive from cairo and starts the configure/build ?
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ f7d3c98eaa001d2d07c1f2b75cad00fa16f86a73
and https://lists.cairographics.org/archives/cairo/2012-October/023675.html
2017-03-17 23:41 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2017-03-17 23:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:
2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-16 21:51 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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@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
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)?
what hack from Igor ? I thought the pharo build just downloads a tar.gz archive from cairo and starts the configure/build ?
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d 3c98eaa001d2d07c1f2b75cad00fa16f86a73
and https://lists.cairographics.org/archives/cairo/2012- October/023675.html
Ok :)
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? nicolai 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com> :
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
Hi Nicolai,
On Jul 22, 2017, at 6:03 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
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",
There isn't a configure script. The choice of which compiler to make, flags to use etc is made in build.win32x86/common/Makefile.rules build.win32x86/common/Makefile.tools and should be able to be overridden by editing build.win32x86/pharo.cog.spur/Makefile
again, this seems to work on the appveyor build but not locally on my machine.
Any idea what I had missed?
nicolai
2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be <philippe.back@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@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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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 <nicolaihess@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
2017-07-22 20:26 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Jul 22, 2017, at 6:03 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
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",
There isn't a configure script. The choice of which compiler to make, flags to use etc is made in build.win32x86/common/Makefile.rules build.win32x86/common/Makefile.tools and should be able to be overridden by editing build.win32x86/pharo.cog.spur/Makefile
The configure script is used by third party libs (for pharo only (pk-config)).
again, this seems to work on the appveyor build but not locally on my machine.
Any idea what I had missed?
nicolai
2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-03-15 9:22 GMT+01:00 philippe.back@highoctane.be < philippe.back@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@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 <nicolaihess@gmail.com>:
2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@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-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 <nicolaihess@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@gmail.com>:
2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com
:
On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess@gmail.com> wrote:
2017-01-22 10:21 GMT+01:00 Clément Bera <bera.clement@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@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
participants (9)
-
Ben Coman -
Clément Bera -
Eliot Miranda -
Esteban Lorenzano -
Nicolai Hess -
Nicolas Cellier -
phil＠highoctane.be -
philippe.back＠highoctane.be -
Stephane Ducasse