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/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Vadim,
On Wed, May 17, 2017 at 01:47:22PM +0300, Vadim Yanitskiy wrote:
> Hi Harald and Craig,
>
> > select.c:27:24: fatal error: sys/select.h: No such file or directory
> > #include <sys/select.h>
>
> I have the same issue with:
>
> gcc-arm-none-eabi 4.8.2-14ubuntu1+6
> binutils-arm-none-eabi 2.24-2ubuntu2+4
> libnewlib-arm-none-eabi 2.1.0-3
Ok, so I'll have some homework to check build in a Debian stable VM and
make that work. Will let you know once I'm done with that.
> > * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
> > libosmocore.git (plus an embedded 'malloc' like umm_malloc)
>
> Why do we need this hack (pseudotalloc)?
Because talloc is large both in terms of runtime memory overhead (for
each allocation) and in terms of code footprint,.
> What if we could cross-compile libtalloc too, and link it against core?
That's possible, but we're talking about microcontrollers with something
like 16kBytes of RAM in total, or maybe less. You cannot afford that
amount of overhead.
> > * have an (optional?) osmocom-bb makefile step to git clone + configure
> > + make install libosmocore
>
> Great idea! What about to have libosmocore as a git submodule inside
> OsmocomBB (like OpenCL headers in hashcat)?
I'm not sure if we'd want that. I haven't really worked much with
submodules yet, though, so my position is not a strong one here.
> Also, I think it would be good to make libosmocore more modular,
> because it could allow us to create more flexible builds (e.g. to compile
> only what we need, not a whole library). This makes sense in case of
> low RAM / ROM embedded systems. What do you think?
linking statically with -ffunction-sections and -fdata-sections will
result the linker in garbage collecting (removing) any functions that
are not used. So I don't think there is any need for a more modular
library, to be honest.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)