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.orgHi Holger,
I added libosmocore commit 7c942ba1475a366cc7c8a129fbdd335166ce21c6
during the camp as at the simtrace/osmocombb/openbsc workshop, several
participants could not build the respective software packages.
This behavior was observed by Kevin and me, and adding subdir-objects
resolved the problem. Due to the hectic nature of a workshop where
everyone is waiting for the build to succeed on the system of all
participants we did not have time to record the specific distribution
versions at that time.
On Debian unstable with autoconf 2.50 / automake 1.15, the build
generates the following warnings:
===============
src/gsm/Makefile.am:15: warning: source file 'milenage/aes-encblock.c' is in a subdirectory,
src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
===============
The project still builds afterwards on this Debian system, so indeed it
is just a warning. However, the warning quite clearly indicates that
the use of subdir-objects is not optional in the future!
So I'm not sure your revert of the assciated commit is the right way to
proceed.
The point seems to be that 'make distclean' wants to remove the
generated objects for the tests, but the latter only are compiled when
'make check' is used, but not in the default build.
Any ideas?
--
- 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)