On Tue, Apr 07, 2009 at 01:22:51AM +0200, Daniel Kobras <kob...@debian.org> wrote: > Hi! > > I'm currently fighting with deb symbols files for a C++ library I'm > packaging, and I'd like to get some insight in how others are coping > with this task. In particular, I wonder how to get rid of symbols from > standard template instances that leak into the ABI, eg. > > $ cat test.cpp > #include <string> > > std::string foome(const std::string& bar) > { > return "foo" + bar + "foo"; > } > > $ g++ -fPIC -c test.cpp > $ readelf -Wds test.o | grep -v UND | grep -v HIDDEN | grep -E > '(FUNC|OBJECT)' > 18: 0000000000000000 23 FUNC WEAK DEFAULT 9 > _ZNSt11char_traitsIcE6lengthEPKc > 22: 0000000000000000 155 FUNC WEAK DEFAULT 11 > _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_ > 30: 0000000000000000 104 FUNC WEAK DEFAULT 14 > _ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_ > 33: 0000000000000000 124 FUNC GLOBAL DEFAULT 5 _Z5foomeRKSs > > I can hide the operator+() and related instances from with a version > script, of course, but due to C++ name mangling they tend to be > arch-specific and thus hard to maintain. Does anyone know of a more > lightweight solution to limit visibility of template instances and > ensure a clean ABI for C++ libraries? What are the current best > practises when writing symbols files for C++ libraries, or is it simply > not recommended?
Unfortunately, gcc upstream consider this as a feature, and not a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022 I found nothing better than using a version script. I'm lucky that the library in question (WebKit) only really exports C symbols, and C++ is only internal details, so I'm filtering everything that starts with _Z, now. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org