In debian, this Osmocom fork of libasn1c is packaged as osmo-libasn1c.
Add related Replaces: and Conflicts: to debian/control, so there is no
error when installing osmo-libasn1c from Debian first, then configuring
the Osmocom package repositories and trying to install libasn1c from
Preparing to unpack .../08-libasn1c1_0.9.34.1.71cb.202302010006_amd64.deb ...
Unpacking libasn1c1:amd64 (0.9.34.1.71cb.202302010006) ...
dpkg: error processing archive /tmp/apt-dpkg-install-8zK3sm/08-libasn1c1_0.9.34.1.71cb.202302010006_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/libasn1c.so.1.0.1', which is also in package osmo-libasn1c1:amd64 0.9.32-1+b1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
The build failures complain about misleading indentation:
../../../src/libasn1c/src/per_decoder.c:161:9: error: this 'if' clause does not guard... [-Werror=misleading-indentation]
161 | if(!td->aper_decoder)
../../../src/libasn1c/src/per_decoder.c:163:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
163 | rval = td->aper_decoder(opt_codec_ctx, td, 0, sptr, &pd);
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all. For those
builds LD shoud be set to clang too (and LDFLAGS needs the sanitizer
flags as well), because the clang compiler driver knows how linking to
the sanitizer libs works, but then at a later stage libtool fails to
actually produce the shared libraries and the build fails. This is fixed
by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan' export
CC=clang-10 ASANPATH=$(dirname `$CC
LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
This reverts commit a352642587d8835deb3c6f55da7986f427835157.
I've confused the libasn1c and asn1c repositories. libasn1c does not
need this workaround, asn1c does.
Related Change-Id: I80eecc60b96e87710218089dfdd1a3f87b40a8b1 (asn1c)
Avoid a race condition that causes the build to fail on Jenkins with:
asn1p_y.y: In function 'asn1p_parse':
asn1p_y.y:357:13: error: 'param' undeclared (first use in this function)
*(void **)param = $1;
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
We updated to 0.9.29 tag, but configure.ac was locked to 0.9.28, which
means release 0.9.29 is going to generated an old version and thus is
broken. A new release will follow this commit.
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
The warning is, on FreeBSD,
asn1helpers.c:68:10: error: comparison of unsigned expression < 0 is always false [-Werror,-Wtautological-compare]
if (len < 0)
~~~ ^ ~
libasn1c is using libm[ath] symbols from REAL.c and hence should be
linked using '-lm' to carry a dynamic linker dependency itself.
We shouldn't use a pkg-config hack to ask applications to do this on
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
In file included from asn1helpers.c:14:0:
../include/asn1c/asn1helpers.h: In function ‘OCTET_STRING_noalloc’:
../include/asn1c/asn1helpers.h:26:9: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
s->buf = str;
asn1helpers.c originally existed in the repository of an application
(osmo-hnbgw, IIRC), and hence was under AGPLv3. When moving it to
this repository, it should have been relicensed but wasn't. The
intention was never to "contaminate" (lib)asn1c with AGPLv3 code.
When decoding a constrained integer with a lower boundary, we need
to make sure the lower bound is added after decoding the raw offset
inside the range.
Before this change, RANAP_CauseMisc_unspecified_failure (115) would be
encoded as 2 (115 - 113 = 2), but would be decoded as 2, rather than
113+2 = 115.
Code for this was taken from
unfortunately doesn't carry much of a revision history :/
The number of bytes used by an APER encoded integer depends on its
actually encoded value, not on the maximum value that could be possibly
The old code would e.g. always use 24 bits if the maximum encoded value
would require 24 bits.
To give an example RANAP MaxBitrate (INTEER 1 .. 16000000) value 64000
was previously encoded as "80 00 f9 ff", while it is now the correct
representation "40 f9 ff".
Thanks to Dieter Spaar for detecting this problem in the Osmo-IUH
generated RANAP output, and thanks to openairinterface for fixing the
bug in their code (sadly not contributed to upstream asn1c, though).
When encoding an INTEGER, we need to subtract the lower bound before
encoding the value. This is specified in Clause 10.5.7.x of X.691.
The decoder already does this correct, but the encoder was wrong.
... which in turn causes all the ASN_DEBUG() to be turned into
fprintf(stderr, ...) statements, once the user application decides
to set 'asn_debug = 1' somewhere in its code.
The next step would be to make _ASN_DECODE_FAILED / _ASN_ENCODE_FAILED
no longer depend on ASN_DEBUG (which it currently does)