On 10 Jul 2017, at 09:38, firstname.lastname@example.org wrote:
On 18 May 2017 at 13:32, Max Leske <email@example.com mailto:firstname.lastname@example.org> wrote:
We managed to figure out that OSProcess works when we use gcc <= 4.8 on Debian. We are happy to use 4.8 for now, so we're good. It would of course be super cool if we could use the series 6 gcc as that will soon ship with Debian 9 (stretch) but it's probably not trivial to just move to a new compiler version (as seems evident from the fact that a minor version change can mess up compilation).
Thanks for tracking this problem down and sharing the details. I came upon exactly the same problem with the Nix package and was able to work-around that by also downgrading to gcc 4.8. I am sure it would have taken a long time to work this out without the benefit of your experience.
Sweet! Nice to know that others benefit from my work (or woes) :)
Relatedly: Is there a suitable automated test that we can use to check that our VMs are basically okay? I am pushing the switch to gcc 4.8 to resolve this problem but I don't know whether this is causing other regressions or what other obvious problems I have missed. I'd love a bit of test coverage for the builds.
There are tests that are being run for every commit to https://github.com/opensmalltalk/opensmalltalk-vm https://github.com/opensmalltalk/opensmalltalk-vm. Unfortunately, they don't explicitly include VM plugin related things. Also, the build is pretty much fixed to a specific GCC version by the build setup (depends on what Travis CI offers, for instance).
I fully agree, that it would be very helpful to have a more elaborate test suite that would take into account things like architecture and available libraries. I think, that could be a nice project for an intern, or a bachelor's thesis (cc'ing pharo-dev and squeak-dev).
As long as we don't have that, I'd use the GCC version from the build. You can get to that by browsing the latest build on travis and searching the log for "gcc" (currently version 4.6.3 on Ubuntu Precise).