2017-07-23 19:42 GMT+02:00 Hernán Morales Durand <hernan.mora...@gmail.com>:

> 2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaih...@gmail.com>:
> >
> > Hm, I tried to create the build environment used for the
> > windows vm build from opensmalltalk.
> >
> > I setup a cygwin environment with the same install commands as from
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml
> >
> > My problems, first it is missing make and wget, I can add make and wget
> to the install command line for cygwin, but I am
> > curious why it is working on the build server ?
> >
> > Anyway, after I got this working, the build stops and building the
> pkg-config package.
> > The log says it can not find a gcc, I know that the build process with
> cygwin uses
> > i686-w64-mingw32-gcc
> > or
> > x86_64-w64-mingw32-gcc
> >
> > But I don't understand where is the missing step to tell the configure
> scripts to use the
> >
> > i686-w64-mingw32-gcc command instead of "gcc",
> >
> > again, this seems to work on the appveyor build but not locally on my
> machine.
> >
> > Any idea what I had missed?
> >
>
> I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in
> your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and
> the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the
> line:
>
> MSYS2_PATH="/usr/local/bin:/usr/bin:/bin"
>
> to
>
> MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/
> bin:/usr/bin:/bin"
>
> And finally
>
> source /etc/profile
>
> Cheers,
>

I always had problems using mingw in the past. I got a working mingw
environment some years ago, and a newer mingw version
did not work well (some changes on the debug and exception format).
But now, the build process for pharo did change. (The build instructions on
github/pharo-vm are old and do not work anymore.

And I hoped to get a more automatic and more reliable build process by
using the same commands used by the build server for
the opensmalltalk pharo vm sources.

And I thought the compiler used to build the latest pharo-vm for windows is
from cygwin ?



>
> Hernán
>
> >
> > nicolai
> >
> >
> >
> > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>
> >>
> >>
> >> 2017-03-15 9:22 GMT+01:00 philippe.b...@highoctane.be <
> philippe.b...@gmail.com>:
> >>>
> >>> I made my own build here.
> >>> Not up to date with latest stuff but should work for the build process.
> >>>
> >>> https://ci.appveyor.com/project/philippeback/pharo-vm
> >>>
> >>> It uses my forked repo and provided you set your own bintray env vars
> for API keys will publish there.
> >>>
> >>> Check all of the output of env vars and where/which in the appveyor
> console to see what gets used when when it comes to compilers and so on as
> there were various compiler versions involved at one point.
> >>>
> >>> Third party cache part is also worth checking.
> >>>
> >>> Still not able to build on my local box at the moment due to some
> tools discrepancies happening.
> >>>
> >>> My build artifacts are embarking too much at this point but allow you
> ro get the release, debug, and assert vms for windows. This helps when
> debugging as backtraces and so on are much more meaningful and one can use
> gdb more effectively to understand what is going on.
> >>>
> >>> Just keep the dlls and exes and you'll be fine.
> >>
> >>
> >> Ah good, thank you.
> >>
> >>
> >>>
> >>>
> >>> HTH
> >>>
> >>> Phil
> >>>
> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaih...@gmail.com> a écrit
> :
> >>>>
> >>>>
> >>>>
> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com>:
> >>>>>>>>
> >>>>>>>> Hi Nicolai,
> >>>>>>>>
> >>>>>>>> If you look at appveyor.yml configuration on https://github.com/
> OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, you will see that
> the pharo brand is not yet in the matrix.
> >>>>>>>>
> >>>>>>>> It's because builds are based on cygwin, but as I understood,
> some library used by some plugin required by pharo refuse to compile with
> cygwin. They appear to work with mingw32.
> >>>>>>>> Cygwin provides headers for legacy directx, some distribution of
> mingw32 did in the past, but it does not seem the case anymore.
> >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They
> are not redistributable and can't be found anymore on the net (too old). We
> cannot seriously base the builds on something so fragile (both technically
> and legally) in the long term.
> >>>>>>>>
> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have
> anything available as a 64bits Microsoft SDK... So pharo has to fix that
> too.
> >>>>>>>>
> >>>>>>>> In the interim, you should look at https://github.com/pharo-
> project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there.
> >>>>>>>
> >>>>>>>
> >>>>>>> Ok, thank you.
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I gave it a shot on sunday, because it was particularly rainy in
> Nantes, and I almost succeeded in compiling all the dependencies with
> cygwin.
> >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely
> forget a few other niceties that some not so well informed programmers
> committed with the faith that it would make their life "easier". It
> certainly does not make mine simpler...
> >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it
> seems that the workaround of Igor does not work anymore.
> >>>>>> ssize_t, WTF???
> >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case
> I'll publish the branch to see how far appveyor goes.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> So I solved the ssize_t problem by removing the hack from Igor which
> is not necessary anymore...
> >>>>> But got another problem soon after while building the tests...
> >>>>> There are trailing lines generated at end of
> tests/cairo-test-constructors.c that make the compilation fail:
> >>>>>
> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I..  -I. -I./pdiff
> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src
> -I../src -D_REENTRANT     -I/cygdrive/y/Smalltalk/
> opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1
>  -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-
> cache/windows/i386/include/libpng16     -Wall -Wextra
> -Wmissing-declarations -Werror-implicit-function-declaration
> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum
> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2
> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers
> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline
> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2
> -Wno-unused-but-set-variable                  -D_REENTRANT  -m32
> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/
> opensmalltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4
> -c -o cairo_test_suite-cairo-test-constructors.o `test -f
> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c
> >>>>> cairo-test-constructors.c:1118:1: attention : la définition de
> données n'a pas de type ni de classe de stockage
> >>>>>  oning ();
> >>>>>  ^
> >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to
> ‘int’ in declaration of ‘oning’ [-Wimplicit-int]
> >>>>> cairo-test-constructors.c:1119:5: attention : la définition de
> données n'a pas de type ni de classe de stockage
> >>>>>      _register_ft_show_glyphs_table ();
> >>>>>      ^
> >>>>>
> >>>>> And the file looks like it has obviously been overwritten, but not
> truncated !!!
> >>>>>
> >>>>> ...
> >>>>> extern void _register_multi_page (void);
> >>>>> extern void _register_fallback_resolution (void);
> >>>>>
> >>>>> void
> >>>>> _cairo_test_runner_register_tests (void)
> >>>>> {
> >>>>>     _register_a1_bug ();
> >>>>>     _register_a1_clip_paint ();
> >>>>> ...
> >>>>>     _register_multi_page ();
> >>>>>     _register_fallback_resolution ();
> >>>>> }
> >>>>> oning ();
> >>>>>     _register_ft_show_glyphs_table ();
> >>>>>     _register_ft_text_vertical_layout_type1 ();
> >>>>>     _register_ft_text_vertical_layout_type3 ();
> >>>>>     _register_ft_text_antialias_none ();
> >>>>>     _register_ps_eps ();
> >>>>>     _register_ps_features ();
> >>>>>     _register_ps_surface_source ();
> >>>>>     _register_svg_surface ();
> >>>>>     _register_svg_clip ();
> >>>>>     _register_svg_surface_source ();
> >>>>>     _register_multi_page ();
> >>>>>     _register_fallback_resolution ();
> >>>>> }
> >>>>>
> >>>>> This file is generated by a shell script test/make-cairo-test-
> constructors.sh
> >>>>> I can't find any reference of the bug, and upgrade to version 1.14.8
> does not solve the issue.
> >>>>> So it will wait until tomorrow...
> >>>>
> >>>>
> >>>>
> >>>> I got the build for windows with mingw nearly working. (it can not
> build some plugins, like SqueakSSL for windows, because the used wincrypt.h
> is different in the mingw distrubtion).
> >>>>
> >>>> I still have the problem, that there seems to be a preprocessing step
> , that should put the vm-version (and source timestamp) in the
> sqSCCSVersion.h
> >>>> I got this working  by running .travis_build.sh (with the options for
> arch/flavor/platform) But how is this done normally when you build a vm
> locally?
> >>>> And how is this done for the pharo-vm we currently use?
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>>>>>
> >>>>>>>> I hope that Esteban will find time to resolve all these problems
> and have pharo brand back on opensmalltalk-vm. I guess that any form of
> help is welcome.
> >>>>>>>>
> >>>>>>>> Nicolas
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>>>>>>>>
> >>>>>>>>> I still have problems building a vm on windows.
> >>>>>>>>> can you give me some hints how to start ?
> >>>>>>>>> I cloned the recent pharo-vm project,
> >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\
> >>>>>>>>> run
> >>>>>>>>> mvm
> >>>>>>>>>
> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not
> found, I had to adjust the include path for finding directx header, missing
> variable replacement for git-versions).
> >>>>>>>>> So I may miss some important steps.
> >>>>>>>>> Is there a repository where I can clone the mingw environment
> used to build the win32-pharo-vm, the environment used on the build-server ?
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>> Nicolai
> >>>>>>>>>
> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <
> esteba...@gmail.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaih...@gmail.com>
> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 Clément Bera <
> bera.clem...@gmail.com>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I believe they're built from https://github.com/
> OpenSmalltalk/vm using travis and appveyor. On the gitbhub readme there
> are relevant links. All built artifacts are also kept on bintray for
> history.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thank you!
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> no, they aren’t :)
> >>>>>>>>>>>> instead, they are built here: https://github.com/pharo-
> project/pharo-vm
> >>>>>>>>>>>>
> >>>>>>>>>>>> (README still not updated)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows
> anymore (something wrong with generating the generator.image, I'll now
> reset my local pharo-vm build directory and see if it works afterwards).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> see attached the stderr log :
> >>>>>>>>>>
> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\
> LoadVMMaker.st'
> >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil
> >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default:
> >>>>>>>>>> BaseSoundSystem class>>initialize
> >>>>>>>>>> MCMethodDefinition>>postloadOver:
> >>>>>>>>>>
> >>>>>>>>>> ....
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on
> master ?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Esteban
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <
> nicolaih...@gmail.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built?
> >>>>>>>>>>>>>> I don't see them on the build server, only the buildresults
> at
> >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last year
> only.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> nicolai
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >
>
>

Reply via email to