Since I still have no real idea how this git stuff works I may have done something wrong here…
I downloaded the new git vm tree using SourceTree (and what an ‘interesting’ experience installing that was; no, not really, it was just unpleasant) and obtained what appears to be a very reasonable pile of files. I did nothing else - no configuring of git stuff.
Then on my Pi I cd’d to the relevant build.linux32ARM/squeak.cog.spur/build directory as usual and ran `sudo ./mvm` as normal. (Hafta use sudo because of some idiocy in xrdp) It seemed to build ok.
Then I went to the ‘products’ directory to copy out the new vm to test. The problem is that the products/cogspurlinuxhtARM/lib/squeak directory contains a directory named ‘5.0-‘. Which means that for some reason the version number has not been generated, found, copied, used, or whatever.
What did I miss?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Loyalty oaths.Secret searches.No-fly lists.Detention without legal recourse.Remind me - who won the cold war?
On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge tim@rowledge.org wrote:
What did I miss?
I believe this can happen if you don't *first* run scripts/updateSCCSVersions after you clone the repository:
https://github.com/OpenSmalltalk/vm#important-notice-for-developers
Regards, -- Bob
On Fri, Jun 24, 2016 at 5:37 AM, Bob Westergaard bwestergaard@gmail.com wrote:
On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge tim@rowledge.org wrote:
What did I miss?
I believe this can happen if you don't *first* run scripts/updateSCCSVersions after you clone the repository:
https://github.com/OpenSmalltalk/vm#important-notice-for-developersRegards, -- Bob
Could mvm be made to look for signs that this has been run and output a warning if it hasn't? cheers -ben
On 23-06-2016, at 7:13 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Jun 24, 2016 at 5:37 AM, Bob Westergaard bwestergaard@gmail.com wrote:
On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge tim@rowledge.org wrote:
What did I miss?
I believe this can happen if you don't *first* run scripts/updateSCCSVersions after you clone the repository:
https://github.com/OpenSmalltalk/vm#important-notice-for-developersRegards, -- Bob
Could mvm be made to look for signs that this has been run and output a warning if it hasn't? cheers -ben
Better yet, surely we could run the damned command if needed...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim This is all a lot simpler and a lot more complicated than you could possibly imagine
On Fri, Jun 24, 2016 at 10:56 AM, tim Rowledge tim@rowledge.org wrote:
On 23-06-2016, at 7:13 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Jun 24, 2016 at 5:37 AM, Bob Westergaard bwestergaard@gmail.com
wrote:
On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge tim@rowledge.org wrote:
What did I miss?
I believe this can happen if you don't *first* run scripts/updateSCCSVersions after you clone the repository:
https://github.com/OpenSmalltalk/vm#important-notice-for-developersRegards, -- Bob
Could mvm be made to look for signs that this has been run and output a
warning if it hasn't?
cheers -ben
Better yet, surely we could run the damned command if needed... tim
Silent failures due to operator error increase the friction to people to get involved, and propagates the error handling to the mail list rather than handling it locally.
But also see my other post "build products seem to go to the wrong branch" where it seems *every* time you change branches you need to run ./mvm... ../../../scripts/updateSCCSVersions #from the build directory so why not make it part of mvm?
cheers -ben
On 23-06-2016, at 2:37 PM, Bob Westergaard bwestergaard@gmail.com wrote:
On Thu, Jun 23, 2016 at 12:54 PM, tim Rowledge tim@rowledge.org wrote:
What did I miss?
I believe this can happen if you don't *first* run scripts/updateSCCSVersions after you clone the repository:
https://github.com/OpenSmalltalk/vm#important-notice-for-developers
This appears to have problems on my Pi - I get two complaints about no such file or directory . ‘cp: cannot create regular file ‘./scripts/../.git/hooks/post-commit’: No such file or directory’ and a simialr one for post-merge I have the .git directory but it contains no ‘hooks’ directory.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim <-------- The information went data way -------->
On 24 June 2016 at 19:40, tim Rowledge tim@rowledge.org wrote:
I have the .git directory but it contains no ‘hooks’ directory.
You can create it when needed; I believe it gets created or not depending on your git version or based on some template, and when it does it only contains example files that do nothing.
In this case, whatever script that tries to cp stuff into it could just do mkdir -p beforehand to ensure the directory is there.
On 25-06-2016, at 7:55 AM, Damien Pollet damien.pollet@gmail.com wrote:
On 24 June 2016 at 19:40, tim Rowledge tim@rowledge.org wrote: I have the .git directory but it contains no ‘hooks’ directory.
You can create it when needed; I believe it gets created or not depending on your git version or based on some template, and when it does it only contains example files that do nothing.
In this case, whatever script that tries to cp stuff into it could just do mkdir -p beforehand to ensure the directory is there.
It looks to me that the ./scripts/updateSCCSVersions is doing exactly that and yet failed to make the .git/hooks directory
And now running it days later it actually makes the hooks directory. Maybe it got updated since I last tried?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
I have a new Raspberry Pi and want to compile the Cog Spur VM.
I fetched the latest from SVN (never mind GitHub for now, I'll do that soon):
$ svn co http://squeakvm.org/svn/squeak/branches/Cog
Then I do a build:
pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm clean? /home/pi/squeak/SVN-Cog/Cog/spursrc /home/pi/squeak/SVN-Cog/Cog/src/plugins checking sanity of generated src directory... okay checking build system type... armv7l-unknown-linux-gnu checking host system type... armv7l-unknown-linux-gnu
Configuring Squeak (.-) for armv7l-linux-gnu
checking whether make sets $(MAKE)... yes checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** No rule to make target 'install-squeak'. Stop.
Does anyone recognize this?
Googling for "compiler cannot create executables" provides lots of random advice, but I don't see a file permissions problem and most of the rest of the advice looks questionable.
The config.log has this (possibly unrelated):
gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated.
That looks like the same gcc version issue I had with building Spur on my Ubuntu laptop. I had thought it might be easier to just buy a $35 Raspberry Pi rather than fix the autotools configure, but maybe not.
Are other people seeing these issues, or is it just me?
Compiling and running an interpreter VM on the same Raspberry Pi works fine, so I am assuming this is either an autotools issue or something related to gcc version for the cog/spur build.
I am attaching the config.log from the ./mvm session in case it helps.
Raspberry Pi OS version information:
pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ cat /proc/version Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016
Thanks, Dave
On Thu, 2016-06-23 at 21:49 -0400, David T. Lewis wrote:
I have a new Raspberry Pi and want to compile the Cog Spur VM.
I fetched the latest from SVN (never mind GitHub for now, I'll do that soon):
$ svn co http://squeakvm.org/svn/squeak/branches/Cog
Then I do a build:
pi@raspberrypi:~/squeak/SVN- Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm clean? /home/pi/squeak/SVN-Cog/Cog/spursrc /home/pi/squeak/SVN-Cog/Cog/src/plugins checking sanity of generated src directory... okay checking build system type... armv7l-unknown-linux-gnu checking host system type... armv7l-unknown-linux-gnu Configuring Squeak (.-) for armv7l-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** No rule to make target 'install-squeak'. Stop.
Does anyone recognize this?
Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. Remove the line with the compiler flags "- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. That fixed the issue for me for ARMv7 builds.
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote:
On Thu, 2016-06-23 at 21:49 -0400, David T. Lewis wrote:
?? I have a new Raspberry Pi and want to compile the Cog Spur VM.
I fetched the latest from SVN (never mind GitHub for now, I'll do that soon):
?? $ svn co http://squeakvm.org/svn/squeak/branches/Cog
Then I do a build:
?? pi@raspberrypi:~/squeak/SVN- Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm ?? clean??? ?? /home/pi/squeak/SVN-Cog/Cog/spursrc ?? /home/pi/squeak/SVN-Cog/Cog/src/plugins ?? checking sanity of generated src directory... okay ?? checking build system type... armv7l-unknown-linux-gnu ?? checking host system type... armv7l-unknown-linux-gnu ???? ?? Configuring Squeak????(.-) for armv7l-linux-gnu ???? ?? checking whether make sets $(MAKE)... yes ?? checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard ?? checking for C compiler default output file name... configure: error: C compiler cannot create executables ?? See `config.log' for more details. ?? make: *** No rule to make target 'install-squeak'.????Stop.
Does anyone recognize this?
Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.
Thank you, Dave
On 23-06-2016, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote:
{snip} Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.\
That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as I know and don’t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get past it…
First thing, try `sudo ./mvm`. If you’re using xrdp to connect to your Pi it makes some odd things happen to do with permissions.
And as for why changing that flag should have anything to do with the problem… frakkin’ insane unix nonsense yet again. Yup, the vm I built this lunchtime has the armv6 flag on. Built perfectly well aside from the sccs version number issue I mentioned before.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother!" said Pooh, as Piglet pressed <START> on the Microwave...
On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote:
On 23-06-2016, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote:
{snip} Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.\
That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as I know and don’t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get past it…
IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)? Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf)
First thing, try `sudo ./mvm`. If you’re using xrdp to connect to your Pi it makes some odd things happen to do with permissions.
And as for why changing that flag should have anything to do with the problem… frakkin’ insane unix nonsense yet again. Yup, the vm I built this lunchtime has the armv6 flag on. Built perfectly well aside from the sccs version number issue I mentioned before.
The Linux world decided a while back that ARMv7 was the minimum for hard float but then the rpi became a thing with its ARMv6 which, unlike many/most other versions of the v6, included hard float. So look at it more as the Linux world viewing ARMv6 as being unsupported like the Intel 486 or older (I think they even bumped that up to Pentium recently)... i.e. it's unsupported by default on modern distros, but of course you can still build a custom distro that supports it as they did for the Pi. So this puts the original Pi in the odd position of being unsupported by any of the armhf distros where the Pi 2 and later can run most of them. But running a non-Raspberry armhf distro likely also means that you have this issue of not being able to build ARMv6 binaries.
On Thu, 2016-06-23 at 23:52 -0400, Phil (list) wrote:
The Linux world decided a while back that ARMv7 was the minimum for hard float but then the rpi became a thing with its ARMv6 which, unlike many/most other versions of the v6, included hard float. So look at it more as the Linux world viewing ARMv6 as being unsupported like the Intel 486 or older (I think they even bumped that up to Pentium recently)... i.e. it's unsupported by default on modern distros, but of course you can still build a custom distro that supports it as they did for the Pi. So this puts the original Pi in the odd position of being unsupported by any of the armhf distros where the Pi 2 and later can run most of them. But running a non-Raspberry armhf distro likely also means that you have this issue of not being able to build ARMv6 binaries.
Just thought of a possibly better way to explain this for anyone who remembers the bad old days: remember how great it was when the Intel 486 came out and you could assume anyone running on a 486 had hardware floating point? Then the 486SX with disabled FP came out and screwed that assumption up. The Pi 1 was essentially the reverse of that: a 386 with a built-in 387 which became wildly popular... not what the Linux world was expecting.
On Fri, Jun 24, 2016 at 12:04:06AM -0400, Phil (list) wrote:
On Thu, 2016-06-23 at 23:52 -0400, Phil (list) wrote:
The Linux world decided a while back that ARMv7 was the minimum for hard float but then the rpi became a thing with its ARMv6 which, unlike many/most other versions of the v6, included hard float. ??So look at it more as the Linux world viewing ARMv6 as being unsupported like the Intel 486 or older (I think they even bumped that up to Pentium recently)... i.e. it's unsupported by default on modern distros, but of course you can still build a custom distro that supports it as they did for the Pi. ??So this puts the original Pi in the odd position of being unsupported by any of the armhf distros where the Pi 2 and later can run most of them. ??But running a non-Raspberry armhf distro likely also means that you have this issue of not being able to build ARMv6 binaries.
Just thought of a possibly better way to explain this for anyone who remembers the bad old days: remember how great it was when the Intel 486 came out and you could assume anyone running on a 486 had hardware floating point? ??Then the 486SX with disabled FP came out and screwed that assumption up. ??The Pi 1 was essentially the reverse of that: a 386 with a built-in 387 which became wildly popular... not what the Linux world was expecting.
Great explanation, thanks.
Dave
On Thu, Jun 23, 2016 at 11:52:48PM -0400, Phil (list) wrote:
On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote:
??
On 23-06-2016, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote:
{snip} Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.\
That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as????I know and don???t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get????past it???
IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. ??Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)? ??Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf)
Also regarding the gcc version, it looks like the configure script is getting rather old. I see this in my config log:
g++: error: unrecognized command line option '-V'
This apparently had no ill effect on the build for Pi, but it's important because I think that the -V option has gone away in recent gcc versions, and that is what prevented me from being able to build Cog/Spur on my Intel Ubuntu laptop. I ran out of patience trying to rebuild the autotools configuration, and that is what finally prompted me to buy this Raspberry Pi :-)
So ... I think that somebody with more patience than me is going to need to update the autotools build one of these days.
Dave
Hi David,
On Jun 24, 2016, at 6:36 AM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 11:52:48PM -0400, Phil (list) wrote:
On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote: ??
On 23-06-2016, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: {snip} Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.\
That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as????I know and don???t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get????past it???
IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. ??Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)? ??Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf)
Also regarding the gcc version, it looks like the configure script is getting rather old. I see this in my config log:
g++: error: unrecognized command line option '-V'
This apparently had no ill effect on the build for Pi, but it's important because I think that the -V option has gone away in recent gcc versions, and that is what prevented me from being able to build Cog/Spur on my Intel Ubuntu laptop. I ran out of patience trying to rebuild the autotools configuration, and that is what finally prompted me to buy this Raspberry Pi :-)
IIRC, the issue is that the default build.linux32ARM produces a VM that will run on Pi 1, which Tim needs for Scratch deployment, and this requires the "-march=armv6 -mfpu=vfp -mfloat-abi=hard" flags. And alas this produces a VM that won't run on, eg, android.
So we really need two build.linux32ARM variants. See below.
So ... I think that somebody with more patience than me is going to need to update the autotools build one of these days.
If you remember the board conversation about moving to github you'll recall I got agreement that I could rewrite the Linux build process to use gmake and makefiles and eliminate autotools. Esteban is working on generating the per-platform config file (cogConfig.h, osvmConfig.h?) that will contain the platform facility defines (such as #define HAS_POLL) that will sit in each build directory, probably in the common directory containing the makefiles (eg build.win32x86/common, build.macos32x86/common, etc) and hence only be generated once per platform. Then we can (if armv6 still makes sense, which for scratch it does) split build.linux32ARM into build.linux32ARMv6 and build.linux32ARMv7 and eventually add build.linux64ARMv8.
We can do this now and have different mvm scripts in build.linux32ARMv6 and build.linux32ARMv7. Feel free to make this split, but be sure to get Travis to build each.
Dave
On Jun 24, 2016, at 6:36 AM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 11:52:48PM -0400, Phil (list) wrote:
On Thu, 2016-06-23 at 19:55 -0700, tim Rowledge wrote: ??
On 23-06-2016, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote: {snip} Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.\
That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as????I know and don???t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get????past it???
IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. ??Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)? ??Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf)
Also regarding the gcc version, it looks like the configure script is getting rather old. I see this in my config log:
g++: error: unrecognized command line option '-V'
This apparently had no ill effect on the build for Pi, but it's important because I think that the -V option has gone away in recent gcc versions, and that is what prevented me from being able to build Cog/Spur on my Intel Ubuntu laptop. I ran out of patience trying to rebuild the autotools configuration, and that is what finally prompted me to buy this Raspberry Pi :-)
With the architecture I've set up one should not attempt to rebuild the autotools configuration in a normal build. You don't need to to add or remove plugins or to choose a specific VM. You only need to when adding new configuration options, or a radically new directory hierarchy, or, as I did this week, changed the generated config.h to include VM_TARGET_CPU et al to replace the bogus VM_HOST_CPU (compiling an x86 vm on an x64 host should not produce a vm that claims to be an x64).
So just use mvm. If you need to edit it, do so, all the levers you need are in mvm plugins.int plugins. ext Part of the idea is to get away from the time consuming hell of running autoconf.
Anyway, soon we'll have gum makefiles for Linux, to match the other platforms, and this insanity will be history.
So ... I think that somebody with more patience than me is going to need to update the autotools build one of these days.
Dave
On 23-06-2016, at 8:52 PM, Phil (list) pbpublist@gmail.com wrote:
IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)?
I’m using the stock latest Raspbian (as I have throughout the last ~4 years) and I’m reasonably sure Eliot is too. The gcc version currently is 4.9.2.
Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf)
To the best of my knowledge Pi uses hardfloat and has for a long time. Let’s see `dpkg —print-architecture` -> armhf So yes, hard float. I think this has been true since ~2013.
Several people have gone to the trouble of compiling Raspbian kernels etc with armv7 settings and found it makes no measurable difference, which means that it would be silly of the Pi people to split things - which of course they would have to do to support the several million older Pis out there. Honestly, since the Pi is probably the main ARM SBC by a very, very, large margin it would be smartest for everyone else to maintain sensible compatibility.
And none of this alters the fact the Eliot & I can build vms without making any arch setting change.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Ignorant, and proud of it.
Tim,
On Fri, 2016-06-24 at 10:32 -0700, tim Rowledge wrote:
On 23-06-2016, at 8:52 PM, Phil (list) pbpublist@gmail.com wrote:
IIRC, it has to do with the build of gcc that is installed for (most?) ARMv7 distros. Are you and Elliot using an armel or armhf based installs or just the stock rpi install (which is ARMv6 hf I think)?
I’m using the stock latest Raspbian (as I have throughout the last ~4 years) and I’m reasonably sure Eliot is too. The gcc version currently is 4.9.2.
Got it. Apologies for not being clearer in my previous comment...
Most of the ARM world (with the notable exception of rpi) is running armhf these days which is where the problem seems to be (i.e. I was able to build using the shipped mvm as-is on armel, but not armhf)
To the best of my knowledge Pi uses hardfloat and has for a long time. Let’s see `dpkg —print-architecture` -> armhf So yes, hard float. I think this has been true since ~2013.
Right, that's the main thing that makes Raspbian different from other Linux distros on ARM: Raspbian is an armhf build for ARMv6. This is *not* what the rest of the Linux world is doing.
It is at least in the ARMv7 armhf (i.e. non-Raspbian) flavor that gcc can't build the VM using the default flags (i.e. the build of gcc doesn't appear to support it). This was the issue for me as I don't build the VM on Raspbian but rather in an ARMv7 VM running (non- Raspbian) armhf for use on my Pi 2 and BeagleBoard-xM. Now, why is Dave seeing this issue presumably running Raspbian on his new Pi? That I don't know...
Several people have gone to the trouble of compiling Raspbian kernels etc with armv7 settings and found it makes no measurable difference, which means that it would be silly of the Pi people to split things - which of course they would have to do to support the several million older Pis out there. Honestly, since the Pi is probably the main ARM SBC by a very, very, large margin it would be smartest for everyone else to maintain sensible compatibility.
This is like saying that since Windows is the main x86 platform by a very, very large margin everyone should fall in line and support it. This doesn't make things run any better for you if you're not on Windows. It's also a narrow view of the ARM platform: if the priority is unit volume then Android/iOS on ARMv7 should be the priority since Pi shipments are rounding error in the ARM ocean. Some of us have been running Linux on ARM since before the Pi existed and/or on different form factors. The good news is that this doesn't need to be an either/or decision: Eliot's post about having multiple build configs for ARM would solve the issue nicely for everyone (i.e. don't assume that everyone is running Raspbian on a Pi, but support it for the majority that do)
And none of this alters the fact the Eliot & I can build vms without making any arch setting change.
That likely solves the problem for the majority of users, but not everyone. The precompiled ARM binaries have been problematic for me for a couple of years (specifically because they have had an incomplete and varying set of plugins) So it's great that they exist, but they aren't the best fit for everyone. And it's also great that the current default build config works for both of you, but again it doesn't work for everyone.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Ignorant, and proud of it.
Thanks, Phil
On Thu, Jun 23, 2016 at 07:55:50PM -0700, tim Rowledge wrote:
On 23-06-2016, at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Jun 23, 2016 at 10:19:23PM -0400, Phil (list) wrote:
{snip} Yes, I ran into it as well... the build is hard-coded to build for the ARMv6 of the original Pi. ??Remove the line with the compiler flags??"- march=armv6 -mfpu=vfp -mfloat-abi=hard" in mvm. ??That fixed the issue for me for ARMv7 builds.
Phil,
Brilliant! I removed the -march=armv6 and it compiles now.\
That is both weird and in some sense wrong; Eliot & I use the armv6 flag so far as I know and don???t have this issue. I *did* have this problem a very long time ago though. The question is whether I can find any evidence of what I did to get past it???
First thing, try `sudo ./mvm`. If you???re using xrdp to connect to your Pi it makes some odd things happen to do with permissions.
I was working through an ssh connection, so sudo was not required.
And as for why changing that flag should have anything to do with the problem??? frakkin??? insane unix nonsense yet again. Yup, the vm I built this lunchtime has the armv6 flag on. Built perfectly well aside from the sccs version number issue I mentioned before.
For reference, my /proc/cpuinfo is (one of the 4 cores): model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 76.80 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4
Compiler version: gcc (Raspbian 4.9.2-10) 4.9.2
Dave
David,
have you read build.linux32ARM/HowToBuild and made sure you've installed the necessary support packages?
_,,,^..^,,,_ (phone)
On Jun 23, 2016, at 6:49 PM, David T. Lewis lewis@mail.msen.com wrote:
I have a new Raspberry Pi and want to compile the Cog Spur VM.
I fetched the latest from SVN (never mind GitHub for now, I'll do that soon):
$ svn co http://squeakvm.org/svn/squeak/branches/Cog
Then I do a build:
pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ ./mvm clean? /home/pi/squeak/SVN-Cog/Cog/spursrc /home/pi/squeak/SVN-Cog/Cog/src/plugins checking sanity of generated src directory... okay checking build system type... armv7l-unknown-linux-gnu checking host system type... armv7l-unknown-linux-gnu
Configuring Squeak (.-) for armv7l-linux-gnu
checking whether make sets $(MAKE)... yes checking for gcc... gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** No rule to make target 'install-squeak'. Stop.
Does anyone recognize this?
Googling for "compiler cannot create executables" provides lots of random advice, but I don't see a file permissions problem and most of the rest of the advice looks questionable.
The config.log has this (possibly unrelated):
gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated.
That looks like the same gcc version issue I had with building Spur on my Ubuntu laptop. I had thought it might be easier to just buy a $35 Raspberry Pi rather than fix the autotools configure, but maybe not.
Are other people seeing these issues, or is it just me?
Compiling and running an interpreter VM on the same Raspberry Pi works fine, so I am assuming this is either an autotools issue or something related to gcc version for the cog/spur build.
I am attaching the config.log from the ./mvm session in case it helps.
Raspberry Pi OS version information:
pi@raspberrypi:~/squeak/SVN-Cog/Cog/build.linux32ARM/squeak.cog.spur/build $ cat /proc/version Linux version 4.1.19-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #858 SMP Tue Mar 15 15:56:00 GMT 2016
Thanks, Dave
<config.log>
Here are useful extracts of messages from Ryan Macnak on the topic. They imply to me the need for separate v6/Pi and v7/Android builds.
On Feb 11, 2016, at 7:43 PM, Ryan Macnak rmacnak@gmail.com wrote:
4) The build is broken on Linux ARMv7 (i.e., everyone but Raspbian). The build fails in the configure step because it includes "-march=armv6 -mfpu=vfp -mfloat-abi=hard" in the compiler flags. This is not a valid configuration for a gcc built to target ARMv7. Removing this from mvm fixes the build. I don't have commit access to the Subversion repository, but someone who does should revert r3410.
On Feb 13, 2016, at 11:21 AM, Ryan Macnak rmacnak@gmail.com wrote:
(Eliot: What is a valid base architecture for Linux ARMv7?)
Rasbian: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard a.c OK gcc -march=armv7 -mfpu=vfp -mfloat-abi=hard a.c ERROR gcc a.c OK
Debian armhf: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard a.c ERROR gcc -march=armv7 -mfpu=vfp -mfloat-abi=hard a.c OK gcc a.c OK
An annoying property of ARM toolchains, which probably comes from ARM being used for embedded systems instead of desktops, is they come with a lot the options already backed in. They aren't like the x86 toolchains, where one can compile to support the latest systems and systems before SSE just by setting some flags. With ARM one has to rely on using an appropriate toolchain.
ARM doesn't have great backwards compatibility either. I've tried running an ARMv6 compiled Cog on an ARMv8 board, and it crashes because the VM includes a memory fence instruction that is deprecated and has a replacement in ARMv7 and optionally (and in practice) disabled in ARMv8. So it doesn't look like one can provide a single binary that supports ARMv6-8. Again the embedded systems mentality that one builds for a specific device.
On 24-06-2016, at 11:09 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Here are useful extracts of messages from Ryan Macnak on the topic. They imply to me the need for separate v6/Pi and v7/Android builds.
On Feb 11, 2016, at 7:43 PM, Ryan Macnak rmacnak@gmail.com wrote:
ARM doesn't have great backwards compatibility either. I've tried running an ARMv6 compiled Cog on an ARMv8 board, and it crashes because the VM includes a memory fence instruction that is deprecated and has a replacement in ARMv7 and optionally (and in practice) disabled in ARMv8. So it doesn't look like one can provide a single binary that supports ARMv6-8. Again the embedded systems mentality that one builds for a specific device.
And yet the cog vms for Raspbian work on Pi3 (ARMv8) Pi2 ARMv7 and Pi B (ARMv6)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Bayard(n): a person armed with the self-confidence of ignorance
On Fri, 2016-06-24 at 11:35 -0700, tim Rowledge wrote:
On 24-06-2016, at 11:09 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Here are useful extracts of messages from Ryan Macnak on the topic. They imply to me the need for separate v6/Pi and v7/Android builds.
On Feb 11, 2016, at 7:43 PM, Ryan Macnak rmacnak@gmail.com wrote:
ARM doesn't have great backwards compatibility either. I've tried running an ARMv6 compiled Cog on an ARMv8 board, and it crashes because the VM includes a memory fence instruction that is deprecated and has a replacement in ARMv7 and optionally (and in practice) disabled in ARMv8. So it doesn't look like one can provide a single binary that supports ARMv6-8. Again the embedded systems mentality that one builds for a specific device.
And yet the cog vms for Raspbian work on Pi3 (ARMv8) Pi2 ARMv7 and Pi B (ARMv6)
Yes, because the Pi Foundation is going to great pains (to the detriment of features and performance on newer Pi boards) to retain backward compatibility. The rest of the ARM world is the wild, wild west. Different strokes and all that...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Bayard(n): a person armed with the self-confidence of ignorance
On 24-06-2016, at 2:27 PM, Phil (list) pbpublist@gmail.com wrote:
{snip}
Yes, because the Pi Foundation is going to great pains (to the detriment of features and performance on newer Pi boards) to retain backward compatibility.
The technical group at Pi Trading (where all the heavy work is done) is larger and smarter than I suspect most of the world understands. Some of them have been working with ARM for as long as I have. Um, which is just under 30 years now. Including using various unixes on ARM since ’88 or thereabouts.
The rest of the ARM world is the wild, wild west. Different strokes and all that…
Yes, and that’s how we set it up.
And none of this is very relevant to working out why Dave had problems compiling the standard setup when neither Eliot nor I do, on supposedly the same hardware and (hopefully) the same OS/compiler. It’s also a bit difficult to see how an arch flag can result in complaints about 'C compiler cannot create executables’.
My config.log is a match for Dave’s reported output for only the first few lines, so something diverges very quickly. The build system and host system agree as armv7l-linux-gnu but I seem to have a check for the target system added. After that it goes differently. The check for the compiler version works ok, and then wher Dave’s fail I get -
configure:2266: checking for C compiler default output file name configure:2269: gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -g -O2 -fwrapv -DNDEBUG -DDEBUGVM=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wl,-z,now conftest.c -lpthread -luuid -lasound >&5 configure:2272: $? = 0 configure:2318: result: a.out
So Dave, which version of Raspbian did you install?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Illiud Latine dici non potest = You can't say that in Latin.
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Bob Westergaard -
Damien Pollet -
David T. Lewis -
Eliot Miranda -
Phil (list) -
tim Rowledge