As you might already know, YateBTS trunk does not compile with
recent versions of GCC, due to a few errors related to iostream manipulations.
These errors are easy to fix in yate-bts source code (see
https://forum.yate.ro/index.php?topic=1966.0).
Though, I was confused why they were not an issue for you, I mean upstream. Which version of GCC do you use ? GCC 4.x, right ?
AFAIK, without otherwise specified:
By default, g++ is equivalent to g++ -std=gnu++14 since GCC 6, and g++ -std=gnu++98 for older releases.
And actually, if I set
-std=gnu++98 in the appropriate Makefile, yate-bts compiles just fine.
My concern is that
-std=gnu++98 and
-std=gnu++14 may be somewhat
different languages, and hence, depending on the C++ features and the GNU extensions the yate-bts source code actually use, and combine, building as
-std=gnu++98 or
-std=gnu++14 may not generate semantically identical object code.
Which makes me think that setting
-std=gnu++98 might be a more consistent fix than (just) patching MSInfo.cpp and Sgsn.cpp to remove the compilation errors. Can someone confirm this ?
IMHO, if it's somewhat important to build the source code as
1998 ISO C++ with GNU extensions, it might be a good idea to enforce this through the Makefiles:
-std=gnu++14 is the default for Ubuntu since Artful 17.10 (and thus for Bionic 18.04 LTS), for Debian since stretch, and obviously for Arch, which sum to a huge Linux users base. BTW, none of these users would be able to build YateBTS out of the box.
The same question may also apply to C code (should we enforce
-std=gnu99 or something else ?).
And may be also when building yate (server) itself: it compiles fine, but should we also enforce standards there ?
Thanks in advance for your answers.
[EDIT]
- I've attached the patches I use to consistently set -std=gnu++98 as C++ standard, and -std=gnu99 as C standard for both yate and yate-bts build files. I'm not sure it's the simplest/best fix, but yate and yate-bts build with GCC 8.2 without the need to otherwise patch the source code.
The diff are against versions 6.1.0-1, and may apply to any 6.x.
- May be it still would not hurt to fix MSInfo.cpp and Sgsn.cpp, though ?
[/EDIT]
Kind regards,
spina.
