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

Neels Hofmeyr nhofmeyr at sysmocom.de
Tue Nov 21 02:06:24 UTC 2017


Ever since I upgraded to debian 9, osmo-hnbgw failed to link in my build:

  /usr/bin/ld: hnbgw.o: undefined reference to symbol 'sctp_send@@VERS_1'

I noticed that adding -lsctp to the build fixed that, yet noticed that no build
slaves nor anyone else seemed to need that.

Some events coincided my re-install of deb9:

- There has always been an -lsctp in the Makefile.am for osmo-hnbgw, but it was
  recently dropped in 
  http://git.osmocom.org/osmo-iuh/commit/?id=7235ea02d78299471d58f4202d8c8d685b1d5772

- I adopted the jenkins.sh -Werror flags in some builds to get fatal warnings.
  Passed by './configure CFLAGS=-Werror'. Someone else added this in jenkins.sh
  and I assumed that was a good way to do things.

- I noticed that I couldn't see debug symbols in gdb, so added 'CLFAGS=-g' in
  my builds. read on...

Comparing with a docker build kindly provided by laforge, I noticed that a
plain 'clone; ./configure; make' does actually succeed on my system!
It is a convolution of CFLAGS causing the error.

By passing a 'CFLAGS=foo' to the osmo-iuh configure script, not only do I add
'foo', but I override CFLAGS defaults, and actually *remove* other CFLAGS.

Turns out, whether I pass CFLAGS=-g or not, -g is always part of the build
command lines: '-g -O2' is the default. Funnily enough, with CFLAGS=-g
passed, I end up removing the -O2 option.

A conclusion here is that in jenkins.sh, we should *not* pass CFLAGS to
configure, so that we don't override any default CFLAGS. A configure option
like --with-strict-warnings can add to CFLAGS in configure.ac instead

So now I guess because I added CFLAGS=-Werror before, I ended up removing -g.
Hence I saw a need to add -g again, goof. Did so in all builds while I was at
it, hence -g ended up in osmo-iuh as well.

The -g stuck around, and building osmo-iuh with CFLAGS=-g does, as I already
said, effectively remove the -O2 option for all things built in osmo-iuh.

Now I'm confused. Why does a lack of -O2 break a linkage.

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


That's all I figured out so far. I still would like to find out why this can
happen, any ideas would be appreciated.

Anyone should be able to reproduce this by building osmo-iuh with
  ./configure CFLAGS=-g

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171121/2dc7f63f/attachment.bin>


More information about the OpenBSC mailing list