[pulseaudio-discuss] Master now has circular build dependency

[Lennart Poettering]

On Sat, 25.10.08 17:42, Colin Guthrie (gmane at colin.guthr.ie) wrote:

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

It's not illogical.

> Normally when I see this kind of approach, a common library 
> provides the shared functionality and then both other libraries share 
> this code.

That's a too simple view of things. You should note the separation
between libpulse and libpulsecommon is not along the lines of "code
used exclusively by clients" and "code used by both the core and by
clients". It is along the lines of "API/ABI stable public client
interfaces" and "API/ABI unstable internal interfaces".

I acknowledge that relying on circular deps is not ideal. I have
tried to find other ways of solving this more elegantly. But I
couldn't think of any.

If you can come up with a scheme that avoids double compilation, keeps
ABI/API stability with the client API, seperates the parts with stable
soname and with unstable soname and does not rely on circular deps
than I am happy to listen!

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

No, it is --no-undefined that breaks this kind of linking. Not the
other way round.

--no-undefined is thought too simple.

> 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 am fully aware that cyclic deps are not the sexiest thing on the
world. I know no better solution however. Also, don't forget that I
discussed this in detail with Diego, who's kind of Gentoo's linking
wizard.

> 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 don't follow.

> Certainly --no-undefined breaks pretty badly and I'd imagine other 
> compilers on other systems may moan too.

Yes, it wight turn out to be problematic on some archs. And I
explained possible solutions for that. 

If you value --as-unneeded more than double compilation I am happy to
take a patch that would optionally enable double compilation for those
symbols in question and not require the cyclic dep. Should be trivial
to add. One possible approach would be to include
$(libpulse_la_SOURCES) in $(libpulsecommon_ at PA_MAJORMINORMICRO@_la_SOURCES) 
if --no-cyclic-deps is passed to configure.

But again. That way you ship libpulse basically twice. Which is what I
wanted to avoid.

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

But splitting up libpulse would mean API/ABI breakage. 

> Either that or the -module idea above if it applies.

I don't follow on this one. Please elaborate.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4