[pulseaudio-discuss] Master now has circular build dependency

[Colin Guthrie]

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


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


Here are our resources on underlinking and overlinking
http://wiki.mandriva.com/en/Underlinking
http://wiki.mandriva.com/en/Overlinking

Here is gentoo's
http://www.gentoo.org/proj/en/qa/asneeded.xml

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

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

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.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]