On Mon, 16 Nov 2009 at 10:01:43 -0600, Ryan Lortie wrote: > Can someone briefly explain to me the difference between the normal, > uninstlaled and no-export pkgconfig files? In normal pkg-config use, you have a normal and optionally an uninstalled .pc file, so you can build against a compiled tree without having to install the library system-wide (see the last few paragraphs of <http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/> for instance). The no-export version of GModule is extra GModule oddness. If you want to link an executable (say, GEdit) in such a way that it can load plugins and those plugins can see its extern symbols, then you have to pass -Wl,--export-dynamic to the compiler when invoking it in link mode (or a conceptually similar rune on non-GNU platforms). gmodule-2.0.pc assumes that you will be linking an executable, so you'll want to do that, and puts the right rune in its Libs line for you. I believe GEdit plugins work like this - this is the more common sort of plugin. The no-export .pc file is the same as the normal one, but does not put -Wl,--export-dynamic in its Libs. You want to use gmodule-no-export-2.0.pc if you're linking GModule into a library rather than into an executable, because (most of) libraries' extern symbols are exported anyway (that's the point of shared libraries). In particular, if you're doing tricks with versioned symbols, libtool --export-symbols-regex or G_GNUC_INTERNAL to hide non-public symbols from the dynamic linker, then using -Wl,--export-dynamic when linking the library is harmful, as it would defeat this effort and export everything anyway. For instance, you might be using an alternative approach to plugins in which all your plugins link against a library that is also linked into the executable, and only use (public) symbols from that library, not from the executable (this has the advantages that the plugins can be compiled with -Wl,-z,defs to catch undefined symbols early, plugins' dependencies are obvious to automated library checks like the ones done by dpkg and rpm, and the ABI of a library is a well-understood thing). Gdk pixbuf loaders are an example of this sort of plugin, I think? IMO the "plain" .pc file should have been the no-export one, and the special one should be gmodule-for-executables-2.0.pc or something; looking in my /usr/lib/pkgconfig I now also see gmodule-export-2.0.pc, which looks like it could be a stepping stone towards deprecating the "plain" .pc file, to force developers to make a conscious decision which one they want to use? Simon
Attachment:
signature.asc
Description: Digital signature