On Mon, 8 Sep 2003, Adam Heath wrote: > On Sat, 23 Aug 2003, Joey Hess wrote: > > > It's interesting to examine what information about maintainers' build > > environments slips into binary packages, and consider the possible > > consequences and what, if anything, we can do about it. > > > > Here's an annotated and edited version of the output of the command > > strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \ > > egrep '/home/.*/' | sort | uniq > > If you're only interested in checking your own packages, I suggest > > instead, > > for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done > > > > /sbin/start-stop-daemon: > > /mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c > > # Given the __assert_fail in the symbol table, this is probably > > # displayed as part of an assertian. One of the more common cases. > > # > > # Of course this leaves the user wondering why the program is > > # complaining about this "adam" person and his nonexistent home > > # directory. Hmm, raid0? > > # > > # Note that assert only puts the full path to a file in if you give that > > # full path to gcc. A minor modification to dpkg's Makefiles would > > # convert this into just "utils/start-stop-daemon.c" and save us all a > > # few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc. > > I've thought about doing this for dpkg's build system, before, because of the > long path that is encoded. > > I'll probably be part of dpkg 2.0.
Ok. I have it fixed. bash-2.05b$ strings build/src/lib/tests/hashtable-test |grep hashtable-test.c ../../../src/lib/tests/hashtable-test.c I might be able to fix it even better, by overriding __FILE__ myself(with -D) on the cmdline, instead of letting it be filled in by cpp from -c.