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/]
