5

Boost: compile latest source or use add-apt-repository

I’m at a junction should I go one way or another…?

Boost 1.55 is part of Raspian Jessie stable, and the advice when installing Domoticz is to use the latest Boost (by compiling the source...), ie. now 1.61, though “as of 19th December 2015 that is version 1.60.”.

(Edit: following advice I have successfully built Domoticz on top of Boost 1.55 using gcc 4:4.9.2-2 (just had to let it have 3 bites at the make)).

I can do one of the following:

a) Ignore the downloaded source (hey ho!) and start with the following and stay within the apt-get system but perhaps stay on the bleeding edge of Boost?

(Edit: I got errors trying to go this way and backed off.):

sudo add-apt-repository ppa:boost-latest/ppa

etc

b) Compile the downloaded source outside of the apt-get system (this seems like a bad idea unless I can re-connect it with the apt-get system...)

(Edit: This seemed unnecessary unless necessary! :-p, so again I backed off.)

I have appropriate backups using rpi-clone to a set of SD cards ;)

  • I have a backup of pre-Boost 1.55 removal (“you will get linking errors if you don't remove the old Boost library”).

  • I have since downloaded Boost 1.61 and could compile it (just doing another separate rpi-clone backup to another SD card)…

Any suggestions welcome…

I've seen these:

Community
  • 1
Geoff
  • 196
  • I'm not clear why you don't want to use the Boost that is packaged for the release you are using. Can you clarify? – Faheem Mitha May 21 '16 at 11:12
  • Hi @faheem, It has been recommended that I use the latest Boost libraries (https://www.domoticz.com/wiki/Installing_and_running_Domoticz_on_a_Raspberry_PI) – Geoff May 21 '16 at 13:00
  • Well, Ok. I see the recommendation. But they don't say why they recommend it. – Faheem Mitha May 21 '16 at 16:45
  • It's not uncommon for devs to give advice like this. Ignore them. They say it because they don't value packaging systems, and find them a burden they want to work around rather than learn. They are narrowly focussed on just their code and don't really give a damn about anything else (especially not the OS their code will run on, or integrating with the rest of your system, their code is special). Many think that packaging is a waste of time, all you need is a git repo or a source tarball. Been there before 1990s, it sucked. Those who fail to learn from history are doomed to repeat it – cas May 21 '16 at 23:31
  • @cas you're missing the fact that (more often than not) the packages in a distro's standard repos can be out of date, and features may be missing, hence the "use the latest version/use x version". this also can be the case when distros have different package versions between them, which could cause conflicts and build issues if the dev has tailored their code to work with a specific version of the package. it also can ensure that the package which they want you to use is installed in a standard/specific location, something which might very over distros (but that is rarely the case). – Joe May 22 '16 at 11:44
  • Thanks for the feedback @cas & Faheem, Am pursuing the packaged path, in fact sticking with good old Boost 1.55 which came packaged with Debian/Raspian Jessie. I'll address any issues as & when ;-) Glad I was so easiliy able to revert to a previous stage, cannot recommend https://github.com/billw2/rpi-clone highly enough ;-) – Geoff May 22 '16 at 11:46
  • personally, I'm always happy with compiling and installing libraries from source if a package doesn't exist in the normal repos (adding ppas and the like becomes a pain eventually). things like the userspace bluez stack I usually compile for source (given they are often modifying/introducing new features). If you never plan to get rid of the boost library, then building the appropriate version from source should be fine. if you only need it for a while, and a ppa has the correct version you need, use that (as it'll be much easier to get rid of :) – Joe May 22 '16 at 11:48
  • Good point @Joe ;-) I know I can build from source if it turns out that I need to :-) Trying add-apt-repository gave me a host of errors which made me think I should try the packaged older version first ;-) – Geoff May 22 '16 at 11:50
  • @Geoff are you sure that the PPA has builds for the pi's architecture (armhf if I recall correctly)? at any rate, you should post the errors from the ppa above :) – Joe May 22 '16 at 11:52
  • Very good point @Joe, thanks. I have no idea... 3 edits added to the original post, I didn't keep a record of the errors (when running sudo apt-get install software-properties-common python-software-properties), but I can load that SD card and generate them again.... I have built Domoticz using gcc, just working out how to run it properly ;-p – Geoff May 22 '16 at 12:13
  • @joe i'm not missing that fact at all. I just don't think it's all that important - certainly not, in most cases, important enough to screw up the system by working around the packaging system rather than working with it. In most cases, it's better to just make do with the old versions of libraries. Failing that, build your own package of the new lib version. Only as a last resort does it make any sense to make install - and even then you should GNU stow or similar to make it easier to clean up the resulting mess when it's no longer needed. – cas May 22 '16 at 12:32
  • "build your own package of the new lib version" - thanks @cas :-), I think that was the clue I was looking for (at the time), and quick links to get someone started in that direction. This looks like a useful HOW-TO: https://linuxconfig.org/easy-way-to-create-a-debian-package-and-local-package-repository. This looks like it would keep source-built stuff within the packaging system. As I say, my Domoticz is now running, but it's good to know the alternative ways to go, with pros & cons ;-) – Geoff May 22 '16 at 13:12
  • I wonder how sensible/easy it would be to package up something like Domoticz (it takes at least half an hour to build on a Raspberry Pi 3 due to memory shortage and hence the necessary make re-starts). Presumably the packages upon which it depends could then be identified/managed? – Geoff May 22 '16 at 13:13
  • @geoff, you might want to look into cross-compiling a package for your rpi3 on a beefier machine - that's one of the benefits of packaging, build it on a fast machine, install on much less powerful machines. I'm no expert on rpis or cross-compiling but this looks like an OK starting point: http://raspberrypi.stackexchange.com/questions/1/how-do-i-build-a-gcc-4-7-toolchain-for-cross-compiling – cas May 23 '16 at 02:14
  • Thanks @cas ;-) So much fun to be had, so little time...:-p – Geoff May 23 '16 at 07:01

0 Answers0