[Poppler-bugs] [Bug 7054] Fix #4481 for broke ABI

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=7054





------- Comment #9 from dmacks at netspace.org  2007-05-31 08:13 PST -------
I'm coming in late to this discussion and know little about how poppler's libs
are arranged, so please bear with me if I ramble a bit...

Is the internal-use library (libpoppler I think) *completely* private and
contains no symbols that are accessed in any way by programs (evince, for
example) that link against the public libraries (libpoppler-glib and
libpoppler-qt)? That is, "nm evince" would list no libpoppler symbols?

So libpoppler itself is hidden from the outside world except that the outside
world knows "it exists". In that case (if I understand darwin's linkers),
evince links against lipoppler but doesn't actually access its symbols, so I
don't think evince is affected by changes to libpoppler's symbols (evince calls
functions in libpoppler-glib which calls functions in libpoppler, not
"everything is hauled into evince and calls happen there").

But really, if libpoppler is an internal convenience library, may as well just
make it really an internal convenience library and not a shared library that
happens to be for private use only.

If you're going to take the .pc route, then sounds like libpoppler is a private
library, not a private package on its own, so Libs.private:-lpoppler sounds
like the way to go. Libs.private is not propagated on OS X. If you have
Requires.private:poppler and a separate poppler.pc, you're still just tempting
folks to link against it directly ("oh, there's poppler, I'll just 'pkg-config
--libs poppler'").


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.