VM building on Pi, OpenGL libraries and other fun things
Locked
VM building on Pi, OpenGL libraries and other fun things
 
|
I’ve been trying to build a Pi vm with the B3DAcceleratorPlugin and FFI access to the openGL library recently. It’s been… interesting. First problem was actually building a vm; I haven’t done that in a month or two and the latest Raspbian combined with the latest Mac OS and the nfs setup I’ve had in use for the last 5 years just didn’t want to function. When I first started using nfs to let me keep all the sources on my iMac and build directly in those directories it worked just fine. Then Raspbian got ‘improved’ by moving to a Debian Jessie base and I had to find out a bunch of new parameters to add to the /etc/fstab line. And it started to need `sudo` so that the `install` command in the makefiles would work. And it had problems with permissions under xrdp. Gradually this has got more and more onerous so recently I converted to using RealVNC, which is after all the Raspbian default now. It’s ok I suppose but having to make the Pi think it has a real monitor attached is a nuisance at times. It does, however, get past a load of the permissions issues and even allows GP to run (see gpblocks.org) despite the SDL stuff being a bit persnickety. Lately though it got completely impossible to persuade the vm build to run properly because of permissions arguments. I spent altogether too much brain-juice on tracking down what might be the problem and I don’t really think I found a satisfactory exposition on the issues. As best I can make out the nfs subsystem simply doesn’t want to accept that uid 20 on the Pi is equivalent to uid 1000 on the mac. One of the complications these days is that the web is so flooded with stuff that googling finds more than you can possibly evaluate and if you are struggling to find really meaningful search terms you’re screwed - you don’t understand enough to be able to get to understand enough. So, I tried a different approach and this is where it might be useful information for others out there; after all nfs is still reasonably common and Pis are everywhere and it is possibly good advice for other combinations anyway. I installed afpfs-ng (never heard of it before) and used that to mount the relevant Mac OS directories. Instant improvement in behaviour. No problem building the vm. I suspect it’s at least in part because you specify the uid/pwd for the access you want instead of semi-magical nfs incantations that no longer work. Bascially `sudo apt-get install afpfs-ng` `mkdir mymountpoint` `chmod og-rwx mymountpoint` `mount_afp afp://username:password@macnameorip/targetdir mymountpoint` or to be more literal mount_afp afp://fred:flintstone@fredMac/squeakdev /home/pi/squeakdev It works with FUSE, so maybe you want to install that too. Once I could actually build the vm I tried adding B3DAcceleratorPlugin to the build list. I’ve actually tried this before several years ago according to my notes and I could swear I’d managed to build it, but nothing in my notes suggests that to be the case. It certainly didn’t want to work now. Looking at the config.log it looked like the GL directory and the relevant header file were in place but the GL library wasn’t found. After much more blundering about I discovered that glXMakeCurrent is actually in libGL (which seemed odd after reading that it is part of openGLX, but that’s unix for you) and that I did indeed have a /usr/lib/libGL.so.1 file (well a link to the ‘real’ library) and yet… no worky. In desperation I made a link for libGL.so without the .1 suffix and… build. Runs Balloon3D examples. So now it would be nice to know why what appears to be a crucial file is not installed. Question for other linux users - do you have a libGL.so file? Did you have to install mesa-common-dev? Can you make a vm with a working B3DAcceleratorPlugin? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- FELIX NAVIDAD - Our cat has a boat |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
On Mon, Aug 07, 2017 at 09:50:14PM -0700, tim Rowledge wrote: > > Question for other linux users - do you have a libGL.so file? Did you have to install mesa-common-dev? Can you make a vm with a working B3DAcceleratorPlugin? > Yes, on my Ubuntu laptop, I did this: sudo apt-get install mesa-common-dev sudo apt-get install libgl1-mesa-dev sudo apt-get install libgles2-mesa-dev Which results in the following being installed: ii libgl1-mesa-dev:amd64 10.5.9-2ubuntu1~vivid2 amd64 free implementation of the OpenGL API -- GLX development files ii libgles2-mesa-dev:amd64 10.5.9-2ubuntu1~vivid2 amd64 free implementation of the OpenGL|ES 2.x API -- development files ii libglib2.0-dev 2.44.1-1ubuntu1 amd64 Development files for the GLib library With Ian's cmake based build, you can exclude GL from the build with the --without-gl option to the configure script, which makes it easy to build a useful VM without the Linux library installation issues. But I do not know of a way to do that with the oscog build process. Dave |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
> On 08-08-2017, at 6:50 AM, David T. Lewis <[hidden email]> wrote: > > > On Mon, Aug 07, 2017 at 09:50:14PM -0700, tim Rowledge wrote: >> >> Question for other linux users - do you have a libGL.so file? Did you have to install mesa-common-dev? Can you make a vm with a working B3DAcceleratorPlugin? >> > > Yes, on my Ubuntu laptop, I did this: > > sudo apt-get install mesa-common-dev > sudo apt-get install libgl1-mesa-dev > sudo apt-get install libgles2-mesa-dev OK, I only (manually) did the first. I still have no clue how to work out what packages you need to do what stuff. I’m sure it’s magnificently documented somewhere, like all software (what, me sarcastic?). Did you get an actual /usr/lib/libGL.so file ? It’s hard to imagine that something apparently crucial doesn’t get installed/created. According to `apt list --installed ` I have these libgl related items as well - i libgl1-mesa-dri - free implementation of the OpenGL API -- DRI m i libgl1-mesa-glx - free implementation of the OpenGL API -- GLX r i libgles1-mesa - free implementation of the OpenGL|ES 1.x API - i libgles2-mesa - free implementation of the OpenGL|ES 2.x API - I suppose I’ll have to assemble a vanilla Raspbian and check that to see what it includes by default. > With Ian's cmake based build, you can exclude GL from the build with > the --without-gl option to the configure script, which makes it easy to > build a useful VM without the Linux library installation issues. But > I do not know of a way to do that with the oscog build process. Same, I think. At least that’s what my ancient notes (old enough to be in Enochian) say. I think. They’ve grown grumpy over the years. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SDR: Shift Disk Right |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
On Tue, Aug 08, 2017 at 01:26:04PM -0700, tim Rowledge wrote: > > > > On 08-08-2017, at 6:50 AM, David T. Lewis <[hidden email]> wrote: > > > > > > On Mon, Aug 07, 2017 at 09:50:14PM -0700, tim Rowledge wrote: > >> > >> Question for other linux users - do you have a libGL.so file? Did you have to install mesa-common-dev? Can you make a vm with a working B3DAcceleratorPlugin? > >> > > > > Yes, on my Ubuntu laptop, I did this: > > > > sudo apt-get install mesa-common-dev > > sudo apt-get install libgl1-mesa-dev > > sudo apt-get install libgles2-mesa-dev > > OK, I only (manually) did the first. I still have no clue how to work out what packages you need to do what stuff. I???m sure it???s magnificently documented somewhere, like all software (what, me sarcastic?). > I'm not sure where it is documented. I think I figured it out by hunting through the mailing lists and/or google queries. > Did you get an actual /usr/lib/libGL.so file ? It???s hard to imagine that something apparently crucial doesn???t get installed/created. > Yes, I have libGL.so. No, it is not (directly) in /usr/lib. But the subdirectories under /usr/lib are organized to support the 32-bit and 64-bit libraries separately, so this looks reasonable. The libGL.so is symlinked to a mesa directory, which presumably (just guessing) would distinguish it from other possible implementations of libGL.so, and that in turn is symlinked to whatever specific version is currently installed, which in my case appears to be libGL.so.1.2.0. This is on an old 64-bit Ubuntu, not 32-bit Raspian, but I find these files on the system: $ locate libGL | xargs ls -l -rw-r--r-- 1 root root 26329848 Aug 1 22:23 /opt/google/chrome/swiftshader/libGLESv2.so lrwxrwxrwx 1 root root 14 Aug 21 2015 /usr/lib/i386-linux-gnu/mesa/libGL.so.1 -> libGL.so.1.2.0 -rw-r--r-- 1 root root 704604 Aug 21 2015 /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0 lrwxrwxrwx 1 root root 21 Aug 21 2015 /usr/lib/x86_64-linux-gnu/libGLESv2.so -> mesa-egl/libGLESv2.so lrwxrwxrwx 1 root root 19 Jul 28 2015 /usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10 -> libGLEWmx.so.1.10.0 -rw-r--r-- 1 root root 497728 Jan 2 2014 /usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10.0 lrwxrwxrwx 1 root root 17 Jul 28 2015 /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10 -> libGLEW.so.1.10.0 -rw-r--r-- 1 root root 555080 Jan 2 2014 /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0 lrwxrwxrwx 1 root root 13 Aug 21 2015 /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so lrwxrwxrwx 1 root root 15 Jul 28 2015 /usr/lib/x86_64-linux-gnu/libGLU.so.1 -> libGLU.so.1.3.1 -rw-r--r-- 1 root root 449232 Oct 21 2013 /usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1 lrwxrwxrwx 1 root root 18 Aug 21 2015 /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so -> libGLESv2.so.2.0.0 lrwxrwxrwx 1 root root 18 Aug 21 2015 /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2 -> libGLESv2.so.2.0.0 -rw-r--r-- 1 root root 26424 Aug 21 2015 /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2.0.0 lrwxrwxrwx 1 root root 14 Aug 21 2015 /usr/lib/x86_64-linux-gnu/mesa/libGL.so -> libGL.so.1.2.0 lrwxrwxrwx 1 root root 14 Aug 21 2015 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 -> libGL.so.1.2.0 -rw-r--r-- 1 root root 635512 Aug 21 2015 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0 Dave > > According to `apt list --installed ` I have these libgl related items as well - > > i libgl1-mesa-dri - free implementation of the OpenGL API -- DRI m > i libgl1-mesa-glx - free implementation of the OpenGL API -- GLX r > i libgles1-mesa - free implementation of the OpenGL|ES 1.x API - > i libgles2-mesa - free implementation of the OpenGL|ES 2.x API - > > I suppose I???ll have to assemble a vanilla Raspbian and check that to see what it includes by default. > > > With Ian's cmake based build, you can exclude GL from the build with > > the --without-gl option to the configure script, which makes it easy to > > build a useful VM without the Linux library installation issues. But > > I do not know of a way to do that with the oscog build process. > > Same, I think. At least that???s what my ancient notes (old enough to be in Enochian) say. I think. They???ve grown grumpy over the years. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: SDR: Shift Disk Right > > |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
In reply to this post by timrowledge
Further info on this afpfs thing - > Bascially > `sudo apt-get install afpfs-ng` > `mkdir mymountpoint` > `chmod og-rwx mymountpoint` > `mount_afp afp://username:password@macnameorip/targetdir mymountpoint` > or to be more literal > mount_afp afp://fred:flintstone@fredMac/squeakdev /home/pi/squeakdev > It works with FUSE, so maybe you want to install that too. Well, trying to add it to my /etc/fstab has been… annoying. It’s not just me, since I’ve found perhaps several hundred web hits from people having a hard time with it. The first part of the problem is that the purported fstab line to use is of the form (from https://sites.google.com/site/alexthepuffin/home by the author) "afpfs#afp://username:mypass@10.211.55.2/alexdevries /tmp/xa20 fuse user=adevries,group=fuse 0 0 “ BUT this prevents the Pi from booting. Urk. By sheer fluke I was doing this test on a Pi that is set to boot from a usb disk so it was reasonably easy to mount it on another Pi and eventually I worked out how to find the fstab and comment out that line. I tried rebooting and then re-enablgin the line and using `sudo mount -a` to see what happens and apparently there was no `afpfs` command; after more fun time googling I discovered this was supposed to be bash script `/sbin/afpfs` that moves around the arguments (why? why ever do them in a different order to the main command?) and then I discovered a page from a Pi book that google had scanned which mentioned manually creating this file. Huh? Not included in the install package? OK, make the script as shown (and eventually found in the source code for the thing) and try that. Nope, refuses to boot, so redo the cross-mounting and modify fstab, again. You get the general gist of it; many hours spent searching, trying ideas suggested by people having related issues, rebooting and so on. I did finally find a version of the fstab line that does allow the boot to complete, albeit very, very, slowly and without actually making the mount available - afpfs#afp://username:[hidden email]/sharename /mountpoint fuse user=osmc,group=fuse,x-systemd.automount,noauto 0 0 So right now I’m stuck and annoyed and frustrated. This isn’t how things should work but seems to have become the standard over the last years. Grrr. Suggestions for solutions welcomed. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CCP: Clear Core and Proceed |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
Hi Tim,
On Wed, Aug 9, 2017 at 7:13 PM, tim Rowledge <[hidden email]> wrote:
You and I talked on the phone yesterday evening but for other's benefit in fstab # is the comment character. See https://wiki.debian.org/fstab. So in the above you probably want to replace # with, say, a tab. HTH
_,,,^..^,,,_ best, Eliot |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
> On 10-08-2017, at 10:43 AM, Eliot Miranda <[hidden email]> wrote: > > You and I talked on the phone yesterday evening but for other's benefit in fstab # is the comment character. See https://wiki.debian.org/fstab. So in the above you probably want to replace # with, say, a tab. Yah, but the really weird thing is that the damn afpfs command *does* actually get the stuff after the # ! No idea why or how. As an example, with /sbin/afpfs defined as #!/bin/bash set -x mount_afp $3 $4 $1 $2 (with the set - x to make it output tracing so I can see what’s happening) and fstab including afpfs#afp://tim:miner5a@Diziet/tim /home/pi/TestDir fuse user=pi,group=root 0 0 You get pi@Goldskin:~ $ sudo mount -all + mount_afp -o rw,group=root,user=pi,exec,suid,dev,dev,suid afp://tim:timpwd@Diziet/tim /home/pi/TestDir Unknown option exec, skipping Unknown option suid, skipping Unknown option dev, skipping Unknown option dev, skipping Unknown option suid, skipping Mounting Diziet from tim on /home/pi/TestDir Mounting of volume tim of server Diziet succeeded. I’m not having any cluefulness of how that ends up working. I can see how the $1 is "afp://tim:…" etc and $2 is "/home/pi/…" but surely the n$3 should be ‘fuse’ and $4 ‘user=pi,group=root’ ? And yet it adds a ‘-o rw,’ swaps the user & group bits, adds ‘suid’ and so on… madness. Just plain madness. Madness of a scale not seen since Mad Mick McMad won the All Scotland Maddest Mad competition The new part that seems to add some goodness was making the group=root instead of ‘fuse’. I tried that because of a comment about ‘the group should be the owner group of the /dev/fuse’ though it also said that ought to be ‘fuse’. Of course, the above fstab line makes mounting with `sudo mount -all` work but does not work when rebooting. To make booting work we have to add the systemd stuff and then - no mounted afpfs connection and trying mount -a doesn’t mount it either. So yeah; computers, eh? I know this really isn’t the best place in the world for all this but y’know - a group of people with simialr interests, plenty of unixisers, some with Pi. I *have* emailed the original author to see if he is still at large and interested. We’ll see. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Loyalty oaths.Secret searches.No-fly lists.Detention without legal recourse.Remind me - who won the cold war? |
|
|
On Fri, Aug 11, 2017 at 2:45 AM, tim Rowledge <[hidden email]> wrote:
If you can't solve the problem, change the problem (again!) nfs bad, afpfs bad, may as well double down and go for the trifecta, maybe try smb? cheers -ben |
Re: VM building on Pi, OpenGL libraries and other fun things
|
|
> On 12-08-2017, at 7:27 AM, Ben Coman <[hidden email]> wrote: > > If you can't solve the problem, change the problem (again!) > nfs bad, afpfs bad, > may as well double down and go for the trifecta, > maybe try smb? Yeah, much though I grew to hate trying to connect via smb in the early Pi days, it seems it’s the least bad option right now. So, children, what have we learned today (well over the last week of mind melting annoyance and stupid software idiosyncracies) NFS is old and getting annoying. Eliot pointed out that you might choose to make users with suitably matching uid/gid values so that logging into nfs on the Mac agrees politely and thus should work. Apparently there is also a way to change uid and so on but I’m really not too interested in delving into arcane unix stuff that far. This is supposed to be a tool, not a lifelong occupation. AFPfs works quite nicely from a commandline mount but simply doesn’t seem to want to work within fstab-world. Also, the package available for Pi seems to be missing a rather important script file for some reason. And it does seem to get lost in recursions of some sort, ones that is spends a lot of time warning about and occasionally locking up processes as a result. Also seems to have become a bit bit-rotted and the author has not been contactable thus far. There are a *lot* of web hits for problems. CIFS/SMB is annoying. Just because it is. It does however appear to function tolerably after far more digging than I ever thought I’d be willing to spend time on. It does at least allow one to connect under the auspices of a particular user and uid/gid set, thus sidestepping the NFS issue that prompted me to go on this ridiculous journey. Getting it to work in fstab-land was even more exciting than you’d imagine. Eventually and hopefully finally, it looks like I have a working system with this setup - make a directory to mount the filesystem to `mkdir /home/pi/aPlace` ensure it has full permissions (not entirely sure if really required) `chmod ugo+rwx aPlace` find out the uid on the pi (seems to be 1000 normally) `id` add this to /etc/fstab "//192.168.1.65/tim /home/pi/DizietFS cifs username=myUsernameOnOtherMachine,password=myPasswordOnOtherMachine,uid=piUID,gid=pi,iocharset=utf8,nounix,sec=ntlmssp,x-systemd.automount 0 0" The nounix & sec= stuff seems to be crucial to connecting properly when booting. The systemd thing is required on a machine using systemd, like any recent Pi. With this lot I can actually reboot, have the Mac FS connected and using the ‘right’ uid/gid, and even compile a vm! Woot! Another thing we’ve learned is that despite fstab having a supposedly specified syntax, almost no file system stuff appears to stick to it. This leads me back to a conclusion I first reached many years ago - We (collectively, software developers) suck. Instead of making things more usable and useful we are making people spend large portions of their lives dig through trash to try to correct idiotic mistakes we dump on them. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim To iterate is human; to recurse, divine. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |