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 [0]. 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 > again.
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 files. 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 > useless. Wildcards are only meant for libraries using properly symbol versioning. Using them as a catchup for possible future new symbols is WRONG. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
