Thanks for the report and suggested fix. AFAICT from quickly digging
through glibc's source, the low-level APIs readdb_preload uses should
be available on all Debian architectures (Linux or otherwise), so it
should actually be possible to use the same (full) symbols file
everywhere by doing away with a spurious #ifdef __linux. Is that
correct, or is there a genuine problem with using madvise() et al. on
non-Linux architectures?
BTW, the approach I use in the one package I maintain that does
require varying .symbols is slightly more sophisticated (and in
particular allows for wildcarding, not that I need it there):
DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
[...]
clean:
rm -f debian/libfltk1.1.symbols.$(DEB_HOST_ARCH)
dh clean
[...]
binary-arch: install-arch-stamp
# Debian still defaults to GCC 4.2 on alpha at present (2008-06-11);
# strip symbols introduced when building with 4.3 regardless of actual
# compiler version so that when the transition occurs, the generated
# dependencies will be suitably tight.
ifeq ($(DEB_HOST_ARCH),alpha)
grep -v '1.1.9-3' debian/libfltk1.1.symbols \
> debian/libfltk1.1.symbols.$(DEB_HOST_ARCH)
endif
[...]
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
