On Fri, Dec 11, 2009 at 9:53 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > (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). >
<snip> > 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. I'll look into this problem this weekend. Using a function would probably simplify the consumers of libxdo that need key map data. So, #3 probably. End result will be libxdo exporting something like xdo_keysym_to_char(), same for symbol_map, and not distributing xdo_util.h with any package as it won't be needed. Thanks again for reporting these things - the old implementation (ship xdo with keynav) was to aid in building where no packages were provided. I am quite happy to move away from that implementation to one that supports packaging models better. :) -Jordan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
