Bug #3867
closedSome older Osmocom program releases don't build against current master libosmo*
0%
Description
From https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/13/console:
Building old tags against libraries from current master... (ERR: new error, err: known error) * libosmo-abis 0.5.0 0.5.1 0.6.0 * libosmocore 0.12.1 1.0.0 1.0.1 * libosmo-netif 0.2.0 0.3.0 0.4.0 * libosmo-sccp 0.9.0 0.10.0 1.0.0 * openbsc 1.0.0 (err) 1.1.0 1.2.0 * osmo-bsc 1.2.1 (err) 1.3.0 1.4.0 (err) * osmo-bts 0.8.0 0.8.1 1.0.0 (ERR) * osmo-ggsn 1.2.1 1.2.2 1.3.0 * osmo-hlr 0.2.0 0.2.1 1.0.0 * osmo-iuh 0.2.0 0.3.0 0.4.0 * osmo-mgw 1.3.0 (err) 1.4.0 (err) 1.5.0 * osmo-msc 1.2.0 1.3.0 (err) 1.3.1 * osmo-pcu 0.5.0 (err) 0.5.1 0.6.0 * osmo-sgsn 1.2.0 (err) 1.3.0 (err) 1.4.0 (err) * osmo-sip-connector 1.1.0 1.1.1 1.2.0 * osmo-trx 0.3.0 0.4.0 1.0.0
The osmo-bts 1.0.0 error is resolved in 1.0.1 (patch).
Related issues
Updated by osmith almost 5 years ago
- Related to Feature #3765: Build old (at least latest) releases of programs against "master of the day" libosmo* added
Updated by osmith almost 5 years ago
- osmo-bsc 1.2.1: depends on libosmo-legacy-mgcp
- osmo-msc: 1.3.0: -Werror and deprecated gsm0480_create_ussd_release_complete()
- osmo-sgsn 1.2.0: sgsn_test.c: gtp.h: No such file or directory
For the rest marked with "(err)", the testsuites don't pass. I am not sure what to do with the testsuites. If we update the expected output to pass on master, then it doesn't pass anymore when building against previous library releases.
Any ideas?
Updated by laforge almost 5 years ago
Hi Oliver,
On Wed, Mar 27, 2019 at 04:00:22PM +0000, osmith [REDMINE] wrote:
Of the tested tags, three fail to build:
- osmo-bsc 1.2.1: depends on libosmo-legacy-mgcp
probably difficult to resolve?
- osmo-msc: 1.3.0: -Werror and deprecated gsm0480_create_ussd_release_complete()
I guess we could simply tag an 1.3.1 patch release to remove that. Also, we could build
without "-Werror"
furthermore, I thought that we had some magic at work to ensure that the OSMO_DEPRECATED
warnings would not break -Werror?
- osmo-sgsn 1.2.0: sgsn_test.c: gtp.h: No such file or directory
probably just some include path issue? Could you have a quick look if it's something
as simple as that? This would probably also justify a patch release as it's quick to do.
For the rest, the testsuites don't pass. I am not sure what to do with the testsuites. If we update the expected output to pass on master, then it doesn't pass anymore when building against previous library releases.
It would be interesting to see exactly where the testsuites fail to determine why that is the case.
Updated by osmith almost 5 years ago
Turns out this is quite feasible:
- osmo-bsc 1.2.1: depends on libosmo-legacy-mgcp
probably difficult to resolve?
- Patch to build libosmo-legacy-mgcp in the CI job (installs into a different temp dir): https://gerrit.osmocom.org/#/c/osmo-ci/+/13454/
- Patch to properly use LIBOSMOLEGACYMGCP_CFLAGS, so we can use the lib from the other temp dir: https://gerrit.osmocom.org/#/c/osmo-bsc/+/13451/
- osmo-msc: 1.3.0: -Werror and deprecated gsm0480_create_ussd_release_complete()
I guess we could simply tag an 1.3.1 patch release to remove that.
In fact, there is already a 1.3.1 version, which does just that :)
Also, we could build without "-Werror"
furthermore, I thought that we had some magic at work to ensure that the OSMO_DEPRECATED
warnings would not break -Werror?
Looking at the build log again, I've not read the error message properly:
gsm_04_80.c: In function ‘msc_send_ussd_reject’: gsm_04_80.c:62:2: error: implicit declaration of function ‘msgb_wrap_with_TL’ [-Werror=implicit-function-declaration] msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY); ^~~~~~~~~~~~~~~~~ gsm_04_80.c: In function ‘msc_send_ussd_release_complete’: gsm_04_80.c:83:9: warning: ‘gsm0480_create_ussd_release_complete’ is deprecated: Use gsm0480_create_release_complete() instead. [-Wdeprecated-declarations] struct msgb *msg = gsm0480_create_ussd_release_complete(); ^~~~
It fails because "msgb_wrap_with_TL" is unknown, not because of the deprecated function.
- osmo-sgsn 1.2.0: sgsn_test.c: gtp.h: No such file or directory
probably just some include path issue? Could you have a quick look if it's something
as simple as that? This would probably also justify a patch release as it's quick to do.
I can look into that soon, currently there is some MSC handover related stuff that I can help with.
For the rest, the testsuites don't pass. I am not sure what to do with the testsuites. If we update the expected output to pass on master, then it doesn't pass anymore when building against previous library releases.
It would be interesting to see exactly where the testsuites fail to determine why that is the case.
Good idea, I'll look into that as well (possibly update the script to attach the testsuite logs to the build artifacts).
Updated by laforge almost 5 years ago
Hi Oliver,
On Thu, Mar 28, 2019 at 03:54:39PM +0000, osmith [REDMINE] wrote:
Also, we could build without "-Werror"
furthermore, I thought that we had some magic at work to ensure that the OSMO_DEPRECATED
warnings would not break -Werror?Looking at the build log again, I've not read the error message properly:
> gsm_04_80.c: In function ‘msc_send_ussd_reject’: > gsm_04_80.c:62:2: error: implicit declaration of function ‘msgb_wrap_with_TL’ [-Werror=implicit-function-declaration] > msgb_wrap_with_TL(msg, GSM0480_IE_FACILITY); > ^~~~~~~~~~~~~~~~~ > gsm_04_80.c: In function ‘msc_send_ussd_release_complete’: > gsm_04_80.c:83:9: warning: ‘gsm0480_create_ussd_release_complete’ is deprecated: Use gsm0480_create_release_complete() instead. [-Wdeprecated-declarations] > struct msgb *msg = gsm0480_create_ussd_release_complete(); > ^~~~ >It fails because "msgb_wrap_with_TL" is unknown, not because of the deprecated function.
Normally one would be able to solve this with a weak symbol, but unfortunately it is (or rather was)
an inline function, so it's not that simple. A possible solution would be to use autoconf
macros to detect if it is present or not and then have related #ifdef in the code to make it
use msgb_push_tl in absence of msgb_wrap_with_TL (and then tag a patch release).
See also Change-Id: If1e851ac605c8d2fde3da565b0bd674ea6350c2e for background on that change.
I can look into that soon, currently there is some MSC handover related stuff that I can help with.
sure, no rush here.
Updated by osmith 10 months ago
- Status changed from New to Closed
Looks like this is not relevant anymore, the most recent 2-3 releases do build against the new libraries from master as ensured by the jenkins job. We currently don't test releases that are older than that, if that is required I suggest creating a new issue.
https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master
If they don't build anymore, we quickly fix up master or make a patch release (see osmo-hlr below).
Currently it looks like this:
* libosmo-abis 1.3.0 1.4.0 1.4.1 * libosmocore 1.6.0 1.7.0 1.8.0 * libosmo-netif 1.1.0 1.2.0 1.3.0 * libosmo-sccp 1.5.0 1.6.0 1.7.0 * openbsc 1.4.0 (err) 1.4.1 (err) 1.4.2 * osmo-bsc 1.9.0 1.9.1 1.10.0 * osmo-bts 1.4.1 1.5.0 1.6.0 * osmo-ggsn 1.9.1 1.10.0 1.10.1 * osmo-hlr 1.5.1 1.6.0 (err) 1.6.1 * osmo-iuh 1.2.0 1.3.0 1.4.0 * osmo-mgw 1.10.1 1.11.0 1.11.1 * osmo-msc 1.8.0 1.9.0 1.10.0 * osmo-pcu 1.0.0 1.1.0 1.2.0 * osmo-sgsn 1.8.0 1.9.0 1.10.0 * osmo-sip-connector 1.6.0 1.6.1 1.6.2 * osmo-trx 1.4.0 1.4.1 1.5.0