6 May
2017
6 May
'17
3:13 p.m.
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:
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.
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. 
8 May
8 May
10:28 a.m.
New subject: FreeBSD C compiler version
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.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
11:41 a.m.
New subject: FreeBSD C compiler version
Hi Max,
On Mon, May 08, 2017 at 10:28:21AM +0200, Max wrote:
This is correct.
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. 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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:11 p.m.
New subject: FreeBSD C compiler version
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>?
2568
days inactive
2570
days old
3 comments
4 participants
participants (4)
-
Harald Welte -
Max -
Pablo Neira Ayuso -
Vadim Yanitskiy