Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x715d42b0 in gcoHAL_QueryChipCount () from /opt/fsl/lib/libGAL.so
[Current thread is 1 (Thread 0x70d674e0 (LWP 5539))]
From some scant info on the web this seems to be caused by a mismatch between the installed OpenGL libs and the Kernel.
[root@organelle2 ~]# uname -a
Linux organelle2 3.14.14+ #7 SMP PREEMPT Wed Nov 4 14:51:27 EST 2015 armv7l GNU/Linux
unfortunately this probably wont help you much, as we dont have access to the kernel headers,
and when I tried to recompile the kernel , I fell into all sorts of holes
Ive tried a couple of times with various different kernel versions, with varying degrees of success… but always failure in the end … then lose the will to try again for a while - then at some point, some other reason crops up, and I try again … don’t know when the next attempt will happen
Ideally we would find a way to get to the latest kernel used by for arch linux (arm) this would then enable us to do a full arch linux update via pacman, which would be really useful!
ok, I cant remember the details, but I do remember when I tried to update the system (including kernel) once via pacman, I did stumble across different versions of the kernel or kernel modules(?) for different openGL implementations. it was complaining about conflicts during the upgrade and asking about upgrading various OpenGL layers/implementations.
so at a random guess, it could be related to that…
(sorry the image i created didn’t boot properly, so I didn’t bother to look into it in any detail, or takes notes… which id have done if id had been successful)
edit: just found some random, incomplete notes i made about it…
something to do with gpu-viv-bin-mx6g-fb and mesa-libgl
well thats what I think my writing says, and there is something about removing stuff and mesa conflicts, and a bit i cant read at all … its times like this i wish my handwriting was more legible
what Id wonder is, if you are building SC, how did you get into a position where libs are mismatching?
did you have to upgrade things from pacman? as ive mentioned previously, this always carries a ‘risk’, as pacman/arch linux is not designed for ‘partial upgrades’
… thats why I said, unfortunately, the best (ideal?) way forward is to get Organelle to work with a modern kernel, and so be able to bring arch linux fully up to date, and so to get all libs/modules/apps all on to a square footing.
btw - why do you want the SC IDE on the Organelle?
the IDE and X are going to consume precious CPU/memory.
personally, I prefer to run the SC server on the Organelle (so that sound is generated there), and run the IDE remotely.
a laptop is ideal - easier than lugging around HDMI monitor/keyboard/mouse.
but if you want to use an existing hdmi/monitor/keyboard, why not just use a rPI running the ide, and remotely connected to your Organelle.
when Ive thought about this myself, its raised interesting questions about my end game/goal
(and ones I keep having to ask myself)
why use Organelle at all for SC?
(one can easily argue a laptop or even rPI + soundcard is more suitable)
my answer is I like creating standalone SC patches that run on organelle… in a similar way to the way we use PD. at this point its disconnect and portable
so the IDE is just use as a development setup to get the patch working - so I don’t even need to use SC for much of the work, I can do it on a Mac (+ OscProxy to integrate the Organelle hardware)
id be really interested to hear - whats your goal? what are you trying to achieve?
I just compared the fsl stuff from a 2.1 image to the ones on my machine and they are the same.
Concerning using the SC IDE on the organelle I just wanted to have everything running on the Organelle, much like we have with PD. So the organelle can be used standalone to knock up supercollider stuff, so If X is running and you select a SC patch the SC IDE is loaded in the same way that the PD editor is now.
I guess it depends on why people get the Organelle, I was always interested in one but purchased mine when you got SC working on it. For me SC is much more interesting than PD.
my assumption is… the image when it was built, should have been cohesive/up to date… but if your updating only bits of the distro then this could break, because you might not be bringing in all dependancies.
(but this of course could be incorrect, it could be it was out of kilter already, but just the apps used were not affected)
Q. on SC IDE , if you build it with the GUI build, are you still able to run SCLang (which is needed for patches) without the GUI/X running? i.e. is there a command line switch like PD -nogui
(as you’ll need sclang to run, even when you just want to run an SC patch, without editing)
Yep some of the dependencies of libGAL.so are different, in fact all of them apart from /usr/lib/ld-linux-armhf.so.3 !
I will knock up a test for gcoHAL_QueryChipCount on the 2.1 image to test, but I’m guessing you have got it right.
There isn’t a -nogui flag, as far as I can see the sclang build (with IDE/QT/OpenGL) requires an X system, so both versions of sclang would be required on the organelle.
I got the IDE running by using the mesa OpenGL libs, there are various little problems but it starts up and the interpreter works, strangely when running on another machine via X the interpreter doesn’t start!
I have some code to test the EGL system as well so when I get some time I will have a look at where it is all going wrong…
