why osmo-hnbgw doesn't build for me, and remaining puzzle

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/.

Harald Welte laforge at gnumonks.org
Tue Nov 21 07:19:06 UTC 2017


On Tue, Nov 21, 2017 at 03:06:24AM +0100, Neels Hofmeyr wrote:
> Now I'm confused. Why does a lack of -O2 break a linkage.

because it removes dead code.

> It's not the osmo-hnbgw linkage per se that seems to be the cause. I can link
> that last step with or without -O2 successfully. It must be a combination of
> building a depending library without -O2 and then linking that to osmo-iuh.
> 
> I diffed the entire build log between a succeeding and a failing build of
> osmo-iuh, and really the only difference everywhere is that the succeeding
> build uses -O2 everywhere.
> 
> The only differences in config.log are the same: most conftest programs have
> -O2 removed, few have a -g added. The conftest conclusions are all identical.
> 

> My big question now is: sctp_send() is actually called from hnbgw.c directly.

this is the big surprise here, as this shouldn't be the case ever we introduced
libosmo-sigtran.

> So IIUC, we should in fact be required to pass -lsctp to the linker for
> osmo-hnbgw. If that is correct, how am I allowed to skip that by passing -O2?

Because the call to sctp_send() is in dead code, specifically in a
static function that the compiler will drop during optimziation.  Hence
the offending symbol reference is gone at the time of linking if any -O
is used.

In I8d52b11e3f476ffd77f3ab185b679817cd3b2163 I introduce the -Wall and
then in subseqent Ifbcb21d43e17bf512bc7b219e590410e06c434ca I remove it.

There's also an interesting catch in I9dbad21e75a55ad91b12d3d3ee8bd6dfb5326c3e
and plenty of warnings fixes in c7a158211fa59ac27c70faa0813a27e2f3a7a569

-- 
- 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)



More information about the OpenBSC mailing list