Project

General

Profile

Bug #3867

Some older Osmocom program releases don't build against current master libosmo*

Added by osmith 7 months ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/27/2019
Due date:
% Done:

0%

Spec Reference:

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

Related to libosmocore - Feature #3765: Build old (at least latest) releases of programs against "master of the day" libosmo*Resolved01/22/2019

History

#1 Updated by osmith 7 months ago

  • Related to Feature #3765: Build old (at least latest) releases of programs against "master of the day" libosmo* added

#2 Updated by osmith 7 months ago

Of the tested tags, three fail to build:
  • 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?

#3 Updated by laforge 7 months 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.

#4 Updated by osmith 7 months ago

  • osmo-bsc 1.2.1: depends on libosmo-legacy-mgcp

probably difficult to resolve?

Turns out this is quite feasible:
  • 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:

https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/15/artifact/_temp/log/osmo-msc-1.3.0.txt

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

#5 Updated by laforge 7 months 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:

https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/15/artifact/_temp/log/osmo-msc-1.3.0.txt

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)