Dear all,
@fixeria: re the C compiler used on the FreeBSD build slave: it is actually, apparently:
FreeBSD clang version 3.4.1 20140512 x86_64-unknown-freebsd10.3
At least that's what a libosmocore ./configure step shows in its config.log.
I would like to start a little discussion about FreeBSD build slave. As it turned out, every new commit is being checked on clang compiler too! It was a bit unexpectedly to me, because we already discussed about this in Gerrit:
https://gerrit.osmocom.org/#/c/2100/
Max:
Do we officially support anything besides gcc?
Harald:
not really, but then it is also nice to be portable. My vote would be to merge the current patch under discussion, but open a ticket as a reminder that this should be made more portable. I suppose mplayer/ffmpeg/fftw or other libs with heavily optimized algorithms also have a solution to that.
Recently I decided to dig into FreeBSD's world, because one of my changes in Gerrit does build fine on Debian slave, but doesn't on FreeBSD. So, I spent a whole night with my laptop and finally installed and configured FreeBSD first time in my experience.
https://gerrit.osmocom.org/#/c/2100/
I am running 11.0 STABLE, and by default it comes with clang as default compiler. There is no GCC installed by default. I tried to build my change with different versions of clang and found the following interesting facts:
- Recent clang-4.0 does support the __builtin_cpu_supports call, so runtime CPU detection should work in this case too. I don't know if it works in other versions. So, I suggest to add a new configure.ac task, which would check whether compiler supports this call or not.
- Regarding to my change, it builds fine on several tested clang versions: clang-3.4.2, clang-3.9, clang-4.0. And I see two possible reasons, why the build fails on FreeBSD:
1) Version 3.4.1 is pretty dated, and we cat try to upgrade it. 2) Clang compiles the source code in a different way, when some SIMD flags are provided. But target CPU doesn't support some of provided SIMD flags. Now in both OsmoTRX and libosmocore we only check whether compiler supports some SIMD flags, but we don't check whether these flags are supported by current build machine CPU. So, lack of the last check and specific optimization / compilation way of clang may cause the fail. I still need to know supported SIMD features of FreeBSD build machine to confirm or refute this assumption.
I also have an idea: what if we could build our projects with several compilers (GCC and clang) and with their several versions (the three latest for example) on Jenkins at the same time? I think, it would be great to keep our projects as portable as possible.
With best regards, Vadim Yanitskiy.
I'd like to share my opinion after recent experience with OpenGGSN. It's very portable - supports GNU/Linux, SunOS, FreeBSD and even Darwin. And that makes code into horrible mess of ifdefs which is hard to follow and update.
On 06.05.2017 15:13, Vadim Yanitskiy wrote:
I also have an idea: what if we could build our projects with several compilers (GCC and clang) and with their several versions (the three latest for example) on Jenkins at the same time? I think, it would be great to keep our projects as portable as possible.
Personally I don't see any benefit in this - if smth compiles on platform X it doesn't mean it really supports it. We can guess that it does but unless someone actually uses it on platform X on a regular basis, it's more of a handwaving: it can fail at runtime, it can fail due to some obscure configuration or file path differences etc.
On the downside - it makes code more complex and harder to follow. I think we should only care about portability to platform X iff there's maintainer who cares about platform X. Someone who's willing to contribute his time (or money) into ensuring that Osmocom stack actually works on it (not just compiles). Otherwise all the efforts spent on making various compiler versions happy are simply wasted.
Hi Max,
On Mon, May 08, 2017 at 10:28:21AM +0200, Max wrote:
I'd like to share my opinion after recent experience with OpenGGSN. It's very portable - supports GNU/Linux, SunOS, FreeBSD and even Darwin. And that makes code into horrible mess of ifdefs which is hard to follow and update.
Well, it's not as bad as you put it. But maybe I'm just remembering too much 1990ies Unix aplication code, where that was more or less the standard, you had to care about portability about a lot of platfomrms...
I also have an idea: what if we could build our projects with several compilers (GCC and clang) and with their several versions (the three latest for example) on Jenkins at the same time? I think, it would be great to keep our projects as portable as possible.
Personally I don't see any benefit in this - if smth compiles on platform X it doesn't mean it really supports it. We can guess that it does but unless someone actually uses it on platform X on a regular basis, it's more of a handwaving: it can fail at runtime, it can fail due to some obscure configuration or file path differences etc.
This is correct.
On the downside - it makes code more complex and harder to follow. I think we should only care about portability to platform X iff there's maintainer who cares about platform X. Someone who's willing to contribute his time (or money) into ensuring that Osmocom stack actually works on it (not just compiles). Otherwise all the efforts spent on making various compiler versions happy are simply wasted.
I agree, but only in as far as it goes beyond FreeBSD. There's quite some point in supporting builds for FreeBSD, as a) a lot of Osmocom infrastructure is running on FreeBSD itself b) FreeBSD has a more reliable SCTP implementation. With AoIP becoming part of the standard setup between OsmoBSC and OsmoMSC (as well as M3UA based Iu on the 3G side), there is quite some value if users can run Osmo* on FreeBSD and not just on Linux.
So I agree with you for cases like Darwin, Solaris, etc. - but not for FreeBSD.
On Mon, May 08, 2017 at 10:28:21AM +0200, Max wrote:
I'd like to share my opinion after recent experience with OpenGGSN. It's very portable - supports GNU/Linux, SunOS, FreeBSD and even Darwin. And that makes code into horrible mess of ifdefs which is hard to follow and update.
Are you refering to lib getopt? Look, there's a note that says:
NOTE: getopt is now part of the C library,...
Probably you can kill those getopt.c and getopt1.c files and use #include <getopt.h>?
-
Harald Welte -
Max -
Pablo Neira Ayuso -
Vadim Yanitskiy