[pulseaudio-discuss] Master now has circular build dependency
gmane at colin.guthr.ie
Sat Oct 25 09:42:25 PDT 2008
Lennart Poettering wrote:
>> Is this deliberate? Is seriously breaks building for me (I can work
>> around it but it's surely not nice to do this?)
> Breaks building? how so?
Well it breaks both --as-needed and --no-undefined GCC switches. I know
you disapprove of this, but it's what I have to work with by default.
I can disable both of these options in this specific spec so I can build
OK. I just find a it a bit illogicial that both libraries require each
other. Normally when I see this kind of approach, a common library
provides the shared functionality and then both other libraries share
> But yes, this is intended to be this way. Up to now we were building a
> lot (and that means really *a lot*) of stuff two or more times: it was
> built into libpulse AND into libpulsecore (and a lot of other
> stuff). To avoid this duplication I have now introduced a third
> library (libpulsecommon) which both libpulse and libpulsecore depend
> on which includes the common parts. libpulse has a stable API/ABI,
> neither libpulsecore nor libpulsecommon have that -- they change API
> every single release. Now libpulse needs to use functions from
> libpulsecommon and the other way round. After some discussions with a
> few people (such as Diego) I decided it is probably OK to have this
> cyclic dependancy on most systems. The dep from libpulse to
> libpulsecore is explicit. The dep the otherwise round is not -- which
> is fine because programs will link against libpulse and
> libpulsecore -- but not exclusively against libpulsecommon. Since
> libpulsecore also pulls in libpulse it is hence guaranteed that all
> symbols can be resolved.
I guess. This cannot be checked at compile time tho' and libpulsecommon
is technically "underlinked" Like I say this fundamentally breaks
Here are our resources on underlinking and overlinking
Here is gentoo's
I wonder if these libraries should really be considered "modules"
(libtool -module option) for this? If so they can be expected to run the
code when loaded into an app, and thus (in our case at least), we
disable --no-undefined (see above Underlinking link).
I'm not expert in this foo to do more than basic guesswork tho'.
> Why not stick libpulsecommon into libpulse? Because libpulse would
> then have a partially stable and a partially unstable ABI/API. This
> cannot be expressed with soname bumps properly and it would be
> difficult to assure that libpulsecore would always be updated at the
> same time as libpulse -- to guarantee that their interfacing stays
Yeah. Can't disagree with that.
> With this "new world order" we now have zero double compilation. Which
> makes compilation of PA quite a bit faster. And disk usage quite a bit
Indeed. I like the idea, I'm just not sure that the cyclical nature is a
good idea for portability.
Certainly --no-undefined breaks pretty badly and I'd imagine other
compilers on other systems may moan too.
I guess the only way to do this is to create a second ABI stable
library. This library would contain all the code from libpulse that is
required by libpulsecommon. This could be built first, then
libpulsecommon, then libpulsecore, then libpulse, without any cyclical
deps. This is probably an oversimplification that wouldn't actually
work, but I'd expect there will be a way to layer things such that it
does not give any cyclical issues.
Either that or the -module idea above if it applies.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss