[pulseaudio-tickets] [Bug 55180] daemon shouldn't depend on libpulse

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=55180

--- Comment #8 from Pierre Ossman <pierre-bugzilla at ossman.eu> ---
(In reply to comment #5)
> 
> Applications can't use the functions in libpulsecommon without linking to it
> directly, and they should not link to it directly.
> 

Actually they can. A short primer on ELF dynamic linking:

When you create an ELF binary, two lists gets put in the result:

 a) A list of missing symbols. E.g. malloc() and pa_simple_new().

 b) A list of _suggested_ libraries where these symbols can be found.

These two lists are not connected in any way. There is no information about
which symbol comes from where, or even if all libraries are needed or
sufficient.

At runtime the system will load all the libraries in list b). It will also load
all libraries that they depend on. So libpulse.so is in b), but
libpulsecommon.so will also get loaded in round 2 because libpulse.so depends
on it.

After this is done, it will start resolving symbols. libpulse.so gets priority
because it was loaded first, but it will not refrain from also looking in
libpulsecommon.so for symbols.


In other words; an application will see all the symbols of your library, _plus_
all the symbols of each and every library that gets loaded as a dependency.


The only fool-proof way of hiding symbols is to put everything in a single .so
file and completely avoid putting those symbols in the export list. Once you
have two .so files you've already lost.

The more common approach is to not try to prevent misuse, but to encourage
proper use. Do this by documenting. No one is going to run objdump on your .so
files to figure out the API. They will be reading your headers and
documentation. So use those files to clearly separate public from private
stuff.

> Having separate copies of the common functionality in libpulse and
> libpulsecore sounds reasonable to me. It would somewhat increase the size on
> disk and memory, but that doesn't sound too bad to me. libpulsecommon could
> still exist as a static library (included in libpulse and libpulsecore) to
> avoid compiling things twice. To see if others have different views, I think
> it would be a good idea to bring up this topic on the mailing list, if
> you're going to work on this.

Not entirely sure libtool will let us to the right thing here. Static libraries
usually don't get compiled with -fPIC. And getting an entire .a file linked is
generally a bit pesky. I don't think compile time is that much of a problem?

> 
> BTW, are you having some practical problems with the current setup, or do
> you want to fix this only because it's ugly to link the daemon to libpulse?

Sorry, it was a while since I did this so I've forgotten the details. :/
The primary issue was reducing the amount of stuff we needed to ship though.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20130412/8033c83d/attachment.html>