* Do not hard-code '-O3' and '-g', let the user decide on them.
* Move '-lpthread' to LIBADD, it shall not be in CFLAGS.
* Also add '-Wall' to AM_CFLAGS.
* AM_CPPFLAGS is for preprocessor flags like '-I' or '-D',
* AM_CFLAGS/AM_CXXFLAGS is for C/C++ compiler flags like '-Wall',
* AM_LDFLAGS is for linker flags like '-no-undefined', not libraries!
* Link ipc-driver-test against libdevice.la,
* Do not put $(UHD_CFLAGS) everywhere.
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
* AM_CPPFLAGS is for preprocessor flags like '-I' or '-D',
* AM_CFLAGS is for C (not C++!) compiler flags like '-Wall'.
* AM_CXXFLAGS is for C++ specific compiler flags like '-Wall'.
By having the preprocessor flags in the proper variable we make
sure that they apply to both *.c and *.cpp files.
The "safe" scaling factor introduced in
7ac54b10d3 is too low and dates back to
the beginning and the move from usrp1->uhd, but the modulator will
exceed +-1 so "proper" scaling leads to overflows. Let's just do what
osmotrx has been doing for many years...
Given integral type A and non integral type B and depending on rounding
mode, optimization, compiler, and phase of the moon A(A)*B != A(A*B) so
split the two cases.
While at it, also make the template automagically work for complex types
instead of requiring manual casts, the general idea here is to allow
inlining and vectorization by treating all args as plain arrays, which is fine.
This works as expected with -tune=native, x64 implies sse2, and we do not
target any neon-less arm versions either.
Clang only array length hints can improve this even more.
5561f1129d introduced some changes,
but while RadioInterface lost its call to close() that was previously
used to improperly reset the buffers upon init() that call was
accidentally not removed for RadioInterfaceMulti and
RadioInterfaceResamp, so those reset previously initialized values to 0
during init(), which break osmo-trx for weird setups.
The MS TRX was intentionally added  as an optional feature, which
requires a git submodule to be present in order to build libtrxcon.
This feature can be enabled by passing --with-mstrx to the configure.
But autoconf/automake is a mess. Despite in the root Makefile.am we
are adding full submodule path to the SUBDIRS *conditionally*, the
configure script would still fail if the submodule is not fetched:
Makefile.am:32: error: required directory
does not exist
It would not even enter that directory if it's present, but somehow
it's still required to exist. For the end user this means that
cloning the submodule becomes a *necessary* step in order to build
osmo-trx from source, even when the MS TRX is not really needed.
The fact that we're unconditionally requiring the submodule, which
is meant to be used by an optional feature feels wrong to me. It's
also unusual for osmocom projects to require submodules, so it may
(and already did) cause build failures when cloning as usual.
Let's work this problem around by defining LIBTRXCON_DIR variable
in configure.ac and using it in the root Makefile.am. If the MS
TRX is not enabled explicitly, make autoconf/automake happy by
assigning LIBTRXCON_DIR the submodule's root directory, which is
always present but empty if the submodule is not fetched.
Related:  b7253c6fdc
Related: OS#5599, OS#5846
Condition 'test ENABLE_MS_TRX' is always true because 'ENABLE_MS_TRX'
is a string literal, not a variable... Because of this, automeke will
unconditionally try to configure the submodule.
This also uncovers very interesting design decisions like the copying of
mutexes and condition vars depending on recursive locks that were
previously hidden by shady c function calls..
We have perfectly good c++11 versions for all of that.
While we're at it, also use the initialization list for the other (still
copy constructable) vectors, which cleans up the radio interfaces.
This is basically a trxcon that includes a transceiver, and can just
be used with existing and future apps supporting the trxcon interface,
i.e. mobile or ccch_scan.
Supports bladerf and uhd.
Currently using hardcoded sched/prios aimed at a setup with working,
reliable usb and reserved cores, for example a raspi 4 (ONLY 4, not 3,
not 2, not any other version)
Additionally builds test tools used for development: osmo-trx-syncthing*
see https://osmocom.org/projects/baseband/wiki/MS-side_GPRS for the
project description and details
Grabbed from gr-gsm 2de47e28ce1fb9a518337bfc0add36c8e3cff5eb
Had a few rounds of extensive cleanup (not the va itself). Uses gcc
multiversioning for x86 targets.
This is not really finished, there are multiple reasons to not use this:
1) main clock is not a gsm multiple, so it will continously drift
2) small buffer sizes lead to tx gaps that are hard to detect and break
- do not lint the submodule
- do not lint the grgsm code
- do not lint headers, checkpatch does not understand that this is a c++
project and any change to existing headers will cause issues.
- also do not do arcane C varargs checks that do not apply to C++
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Avoid building osmo-trx a second time on arm during "make distcheck". If
the build of osmo-trx already passed on arm, running "make distcheck"
should give the exact same result as on x86_64.
This should shorten the build time significantly for osmo-trx jobs
running on raspberry pis, currently they take half an hour.
Fix for the following error we see since building master-osmo-trx on
debian 10 instead of 9:
/usr/bin/ld: ipc_driver_test-uhdwrap.o: undefined reference to symbol '_ZTIN5boost6detail16thread_data_baseE'
/usr/bin/ld: //usr/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0: error adding symbols: DSO missing from command line
After spending a lot of time on researching this, my understanding is
now that uhd.pc should have had "-lboost_thread" in versions up to the
latest release 4.2.0 because before that it would include boost thread
headers in its logging code:
ld is able to figure out which library provides the missing symbol, and
apparently depending on the binutils version and linker flags, it may
just ignore this and not show an error. This is why apparently it worked
with debian 9 and still does work in OBS (different flags), and why it
was not fixed upstream in uhd.pc. By now fixing it is not needed in the
latest version anymore, and there are already versions of uhd.pc in
various linux distributions without -lboost_thread, so I think it's
appropriate to add the workaround here in configure.ac.
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.