Long story short:
* Updated tools/sparse
* Compiles fine on my side (Debian 8)
* Blows up on buildbot (slave-lede-local) because it runs GCC 4.7 (lacks bswap, 4.8+ works according to https://sourceware.org/bugzilla/show_bug.cgi?id=20530)

Having a look at the buildbots, it shows that tictex-02 uses GCC 4.9 (probably Debian 8) while slave-lede-local runs Debian 7 (LTS). I have on idea what the phase2 buildbots uses however as the web interface doesn't say.

However this bring my question about what we are targeting and what's the view on supported versions and common lowest denominator?

Version of base GCC on common distros, haven't looked at external packages:
Debian 7 (LTS): 4.7
Debian 8: 4.9
RHEL/CentOS 7.3: 4.8
Ubuntu 16.04.2 (LTS): 5.3.0
Ubuntu 17.04: 6.3.0
Arch Linux: 6.3.1
Linux Mint 17.3: 4.8.4
FreeBSD 10.3/11.0: 5.4.0 (default via ports)

We already have requirements for a few utils and libs so I don't think it's a huge deal in the end.
This should probably be adjusted as it tests for really old versions of GCC etc.

While hacking in bswap in this case isn't an issue it however raises the question of what we want to support and for how long. Also, do we want unified buildbots? It's been mentioned on Github that some build bots doesn't support all download protocols or at least have issues with a few such as svn, I don't if that's the case anymore but do we have any guidelines for such setups? Bots also have different software installed meaning that some packages fails depending on bot, however I'm not sure if that applies to any of the current packages but it occurred in the past. Jo-Philipp Wich also pointed out on irc that using different versions also irons out bugs, while this is true it also adds a lot more of complexity to debugging. Perhaps we should try to have a unified setup first and have "experimental" bots later on if there's capacity?

Best regards,

Lede-dev mailing list

Reply via email to