This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comHi Max and Harald, As I mentioned above, my suggestion is to keep the source code "as portable as possible", which doesn't mean absolutely portable. I don't suggest to add other UNIX platforms (Darwin, Solaris, etc.) to our portability scope, I suggest to perform checks on the same platforms as we currently do, but additionally to have both Clang and GCC on both slaves. Why Clang? - it's default compiler on FreeBSD (recent distributions); - it has its own big community; - it has growing compatibility with GCC, see: en.wikipedia.org/wiki/Clang#Performance_and_GCC_compatibility Why different versions? - different distributions provide different versions available out of the box, i.e. some (such as FreeBSD) provide the latest version, while some other provide a bit dated versions; - some things may change in newer versions, e.g. from my recent experience: Clang 4.0 has support of the __builtin_cpu_supports built-in, while older versions don't. I see the only disadvantage of this approach - longer total build time. So, if you guys support this idea, I could do all configuration and installation related work. Also, I'll try to contribute some computing power to Jenkins: there are some servers in my university, which power isn't used anyhow, so they mostly idle all the time. > 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. Here I found the problem. Cite from GCC's documentation page x86-Built-in-Functions.html at gcc.gnu.org: > If you specify command-line switches such as -msse, the compiler > could use the extended instruction sets even if the built-ins > are not used explicitly in the program. For this reason, applications > that perform run-time CPU detection must compile separate files for > each supported architecture, using the appropriate flags. In > particular, the file containing the CPU detection code should be > compiled without these options. Adding SIMD flags to a whole project breaks portability between different CPUs, so I added these flags for viterbi_sse.lo only. Now the problem seems solved. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170509/e81a2859/attachment.htm>