On Sun, 20 Jul 2008, Michael Tautschnig wrote:
> I just added a symbols control file to the latest upload of the diagnostics
> library. I started out with a single libdiagnostics0.symbols file, which caused
> an FTBFS on all archs . So we all know that C++ name mangling has its
> downsides, but in this case it becomes a real PITA. Though, it is questionable
> whether C++ name mangling is the issue, or symbol files are just broken by
> design. Obviously I will now create arch-specific symbol files, but what if we
> ever add a new symbol to diagnostics? Quite likely, things will FTBFS once
It's the job of the maintainer to maintain the symbols files, if you don't
accept it (with all its complexity in your case), just don't use symbols
But to correct you: newly added symbols do _not_ generate FTFBS by default
(though they will generate a lintian warning), only removed symbols result
in a FTBFS by default.
If new symbols appear, just add the new symbols to your symbols file. The
rules for symbol mangling depend on the architecture but they are "fixed"
for each architecture so one could write an helper script to update all
the symbols file.
And FYI, I have worked in the open with several rounds of review on -devel
when I developed the symbols files. The limitation of symbols in C++
binaries were exposed but I haven't had any concrete suggestion on how to
handle them better.
> Of course, I could add some wildcard, but this renders symbol files more or less
Wildcards are only meant for libraries using properly symbol versioning.
Using them as a catchup for possible future new symbols is WRONG.
Le best-seller français mis à jour pour Debian Etch :
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com