My advise is to try first the pre-built linux binaries available at:
they may or may not work, I suspect at the very least you’ll have to figure out where libserialport should go on your system. It might even be suitable to build against, not sure.
… either way, it could give me some pointers as how to refine potential support on Ubuntu without requiring to build from source.
PS: and err yeah, if compiling and deploying was as easy as the comment made on the blog was, we could all live a happy (but boring) life ever after!
You can substitute the instructions supplied ( for compiling libserialport ) with these:
git clone https://github.com/martinling/libserialport
cd libserialport
./autogen.sh
./configure --prefix=/usr/local
make
sudo make install
I’d like to piece together full linux build instructions since it’s really not that complicated and I recently completed a build on Linux Mint 17.2. The main problem is it necessitates you having a lot of build tools installed that you may not otherwise desire!
That said, I’m more than happy trying to help you figuring out the missing part in your compilation jigsaw, but you have to post exact messages received… I suspect you simply need to cd in the right directory to build libserialport, but that’s just a wild guess!
EDIT: follow @gadgetoid instructions, the sources for libserialport are more suitable than those currently included in the ‘VS’ repo.
Build script I’m now trying on Linux Mint 17.3 ( which is based upon Ubuntu 14.04.3 ):
#!/bin/bash
sudo apt-get install --yes build-essential
sudo apt-get install --yes libtool autoconf automake cmake
sudo apt-get install --yes libboost1.55-dev libboost-system1.55-dev libboost-program-options1.55-dev libboost-filesystem1.55-dev libboost-date-time1.55-dev
git clone --depth=1 https://github.com/martinling/libserialport
cd libserialport
./autogen.sh
./configure
make
sudo make install
cd ..
git clone --depth=1 https://github.com/zaphoyd/websocketpp
cd websocketpp
mkdir build
cd build
cmake ..
make
sudo make install
cd ../../
git clone --depth=1 https://github.com/pimoroni/flotilla-daemon-vs
cd flotilla-daemon-vs/Flotilla
make CC=g++
This now works in both ShipShape and Master. I’ve fixed the master Makefile so it no longer explodes the linker after compiling. D’oh.
If you want to use ShipShape ( recommend, it’s sooo much better ) then add -b ship to the end of git clone --depth=1 https://github.com/pimoroni/flotilla-daemon-vs to target that branch.
This may not be a straight copy & paste affair since your Ubuntu install may not have the right versions of Libboost or g++ out of the box, but it’s usually easy enough to find them yourself by doing something like:
apt-cache search libboost
And picking an available version number ( 1.50, 1.55 or 1.6x ) to substitute into the script above.
Compiling stuff can be painful and lead to some very, very obscure error output, but it’s a learning exercise!
Once compiled, the binary will be in the Flotilla folder:
cd flotilla-daemon-vs/Flotilla/Debug
./flotillad -d
You may also have to add your user to the dialout group, or you’ll get tons of ‘unable to open port’ errors when you actually run the Daemon- as I just discovered on mint!
I just need to plug in the dock later on this evening.
Once again, that you both for the pointers and fantastic support.
For anyone else who has an odd setup like me:
Chromebook running Ubuntu 14.04 with XFCE in a Crouton chroot
Running '**python rockpool.py**' launches the ChromeOS browser.
An unexpected surprise, but a nice one.
Good news to know it can be fudged onto a Chromebook, we’ve got one kicking around that might make a great portable demo-unit. WiFi inevitably fails us in venues :(
On a fresh Ubuntu install, with flotilla-pre cloned from git, I ran: sudo ./install_dependencies
All ran OK with the nice ‘All Done!’ message.
However, when I run: sudo ./launch_flotilla
or just ./launch_flotilla
I get: ./flotillad/flotilla-i386: error while loading shared libraries: libboost_system.so.1.55.0: cannot open shared object file: No such file or directory
That particular binary was compiled under Debian 8.3 on a notebook with a 32-bit instruction set CPU. I’m not sure what would happen on anything else… I suspect that could be the problem, namely that you’d need boost libs that match the arch of the build.
Your best bet may be to compile from source using @gadgetoid script, it should be easy enough, hopefully.