This was gathered by one of my analysis scripts: Symbol gfree@@ (64-bit UNIX System V ABI AMD x86-64 architecture) present 3 times /usr/lib64/libpoppler.so.2.0.0 /usr/lib64/libgunicode.so.3.0.0 /usr/kde/3.5/lib64/kde3/libkpdfpart.so (Don't mind libkpdfpart) I think gfree should be either renamed or hidden in poppler to avoid possible collisions, the name is quite generic as it is.
I am opposed - to rename this symbol will make future merging from xpdf harder. Why do you think it should be renamed in poppler? Why not the other library?
Really just because I think you're more active and open to discuss problems :)
Is gfree (and the rest of goo for that matter) part of the public interface for poppler, or is it just internal implementation? That is, could gmem() become a private symbol and solve this mess?
Techincally it's internal but there are lots of projects out there ignoring our suggestion not to use poppler internals and still using them so well, it's also kind of public.
D'oh! Well, privatizing would sure break 'em of that habit:) Maybe something to consider when there's a future ABI break for some other reason?
I'm going to close this, to be honest we are not going to change it, so keeping it open is just silly. Hope not much people tries to use libgunicode and poppler at the same time
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.