(pulling Jordan into the loop here. Jordan, this discussion is recorded in full at http://bugs.debian.org/560176 )
On 12/11/2009 02:57 AM, Wen-Yen Chuang wrote: > The git one made symbol_map static, which will make keynav FTBFS. > > Build log: > keynav.o: In function `parse_mods': > keynav.c:(.text+0x1b2): undefined reference to `symbol_map' > keynav.c:(.text+0x1d2): undefined reference to `symbol_map' > keynav.c:(.text+0x1e3): undefined reference to `symbol_map' > collect2: ld returned 1 exit status > make[1]: *** [keynav] Error 1 yeah, this is a problem with the current xdotool source, i think. Note that xdo.h does not contain any declaration for symbol_map currently (and we're not shipping xdo_util.h with libxdo-dev), so applications building against it have no way of knowing that symbol_map is even available (keynav only knows about it because it happens to have the same upstream author). So the simpler fixes to this present fairly unsatisfactory resolutions: 0) if we were to ship libxdo0 with xdo_util.h as it currently stands, then any tool (like keynav) which does a #include <xdo_util.h> will create a *duplicate* definition of symbol_map. if this ends up changing (say, new values are added to symbol_map in a new release of libxdo0), then which version would the compiled keynav use? this seems troublesome. 1) if we were to add a declaration for symbol_map to xdo.h, keep on not shipping xdo_util.h, and remove the static marker in xdo_util.h for symbol_map (similar to your patch), then i'd be concerned that we'd be polluting the global namespace: should libxdo really claim a global variable named "symbol_map" ? it seems like a very general name that might already be in use by other projects. This leaves slightly more complex fixes as possibilities: 2) go with the same arrangement as (1), but re-name the table to something like xdo_symbol_map, or 3) have libxdo export a new function, (named perhaps xdo_symbol_map()) that does a lookup in the static symbol_map on behalf of the caller. > You may try the updated keynav on mentors.debian.net: > - dget > http://mentors.debian.net/debian/pool/main/k/keynav/keynav_0.20091208.01-1.dsc > > I have made it to use system header and system library. :-) cool, thanks. I'll take a look at it when i get a chance. This might take a coordinated fix between the two packages, but hopefully that will be a one-time thing, and we can move forward with a clean shared object for future versions. Thanks for working on this, Wen-Yen! Regards, --dkg
signature.asc
Description: OpenPGP digital signature
