This patch solves two different issues at the same time when building
with gcc/g++ 9.2.0:
1) The -fvisibility=hidden support check was done using the C++
compiler only (with check_cxx_compiler_flag), inside the block
corresponding to the C compiler being GNU/clang, and the result of
the check was applied to both C++ (CXX_FLAGS) and C (C_FLAGS) flags.
Instead of this, there should be separate checks for the C and C++
compilers, each of them modifying a single set of <LANG>_FLAGS.
2) -Wincompatible-pointer-types support check was done using the C++
compiler only, and the result of the check was applied to both C++
(CXX_FLAGS) and C (C_FLAGS) flags. But, this warning is not
applicable to C++ and actually breaks compilation when using g++ 9.2:
[ 0%] Building CXX object lib/src/asn1/CMakeFiles/rrc_asn1.dir/rrc_asn1.cc.o
cc1plus: error: ‘-Werror=’ argument ‘-Werror=incompatible-pointer-types’ is not valid for C++ [-Werror]
Instead of this, there should be a check for this warning only using
the C compiler, and therefore only modifying the C flags (C_FLAGS).
This patch splits the macro into one specific for C++ (which modifies
CXX_FLAGS) and one specific for C (which modifies C_FLAGS). And so,
the macro call to check for `-Werror=incompatible-pointer-types' is
made C-only, and the one for `-fvisibility=hidden` is done for both C
and C++ targets (each on the correct GNU/clang compiler block).
Due to how the tests are done in cmake, the '-fvisibility=hidden'
check wasn't even succeding before, so the compiler option wasn't
being effectively used. The cmake flags.make file contents throughout
the project are updated as follows now:
Before this change, we had:
C_FLAGS = -Werror=incompatible-pointer-types ...
CXX_FLAGS = -Werror=incompatible-pointer-types ...
And after this change, we have:
C_FLAGS = -Werror=incompatible-pointer-types -fvisibility=hidden ...
CXX_FLAGS = -fvisibility=hidden ...
move non-type-specific methods of proc_t to its base class.
procedure state machine was simplified via a future-type. Now procedures dont get stuck until the user reads the procedure outcome.
made the NAS procedures more event trigger/reaction-based.
before cell reselection was postponed to the next TTI but this is not possible in
the case where the serving cell changes.
if the "old" serving cell is no longer suitable, we would directly go to RRC IDLE below.
Therefore we need to select the new serving cell before sending the reestablishment
request.
this is tested in TC_8_5_1_1
Francisco Paisana
Andre Puschmann
Aleksander Morgado
Francisco Paisana
Ismael Gomez
Xavier Arteaga
Pedro Alvarez