Bug 11969

Building rarian-0.5.6 on OS X 10.3 (gcc3.3), I get many linker warnings:


g++-3.3 -g -O2 -o .libs/rarian-sk-migrate rarian-sk-migrate.o tinystr.o tinyxml.o tinyxmlerror.o tinyxmlparser.o rarian-reg-full.o -Wl,-bind_at_load  -L/sw/lib ../librarian/.libs/librarian.dylib
ld: warning multiple definitions of symbol TiXmlDeclaration::operator=(TiXmlDeclaration const&)
tinyxml.o definition of TiXmlDeclaration::operator=(TiXmlDeclaration const&) in section (__TEXT,__text)
../librarian/.libs/librarian.dylib(single module) definition of TiXmlDeclaration::operator=(TiXmlDeclaration const&)
ld: warning multiple definitions of symbol TiXmlDocument::LoadFile(TiXmlEncoding)
tinyxml.o definition of TiXmlDocument::LoadFile(TiXmlEncoding) in section (__TEXT,__text)
../librarian/.libs/librarian.dylib(single module) definition of TiXmlDocument::LoadFile(TiXmlEncoding)

and similar for many dozens of symbols in these two files. The issue is that tinyxml.o is linked into rarian-sk-migrate directly, but tinyxml.o is also linked into librarian which is linked into rarian-sk-migrate. Oh sure, it's the same object file, but linker doesn't know that:)

If tinyxml is embedded in librarian, no need to link it explicitly as well I don't think. OTOH, it looks like tinyxml is a self-contained convenience library but is also not really "part of" librarian or needing to be available in the public interface to librarian, in which case maybe its symbols should be downgraded to private in the ABI?

Taking a step back, this is a pretty entangled mess, and makes it possibly complicated to upgrade tinyxml in the future. Might be lots clearer (and pave the way for possible future use of an external tinyxml lib) to place tinyxml in its own subdir and roll it as a libtool convenience library.