FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-02-2010, 08:04 AM
Michael Tautschnig
 
Default dpkg-gensymbols and C++ (once again)

Hi all,

With the recent upload of diagnostics I've again been bitten by dpkg-gensymbols
[1]. As you might notice, the symbol is/was there, just the mangling scheme
seems to have changed. For one, the next upload will be the third upload just to
fix changed symbol names on alpha. One could argue that I should have built the
package on an alpha system beforehand to avoid such brokenness. Well, I did.
Most probably the g++ versions used on albeniz.d.o and goetz just don't match.
Similarly, archive-rebuilds will show more or less spurious FTBFS (e.g.,
#562397 -- I'm building binary packages on amd64 myself).

I understand that symbol files could help to improve quality of our archives
and, as diagnostics is about software quality as well, I'd tend to support this
as well as possible. At the current stage, however, this seems hardly feasible
with C++ libraries, unless I'm doing something wrong.

Couldn't the following be implemented, maybe as some C++ mode of dpkg-gensymbols?
- Instead of mangled symbol names, source packages should ship demangled symbol
files. This way, package maintainers could truly inspect those lists of
symbols and maintain them in a sane way (like manually adding symbols as the
API evolves). The symbol names would remain independent of the architecture
and sorted in some logical way (i.e., by C++ namespace and class names),
unintended symbols as part of those lists would become obvious, etc.
- Pending realizability using g++ or the like, these lists are converted to
their architecture-specific variants consisting of mangled names by
dpkg-gensymbols.
- Subsequently, the mangled list and the contents of the library should be
compared and (as done currently) deviances reported. It would be nice, of
course, to demangle missing and/or additional symbol names.
- The mangled list (generated from the list of the source package) should then
be shipped in the binary package.

I guess the facilities to mangle/demangle are there, I just don't know whether
they are accessible from the command line.

Best,
Michael

[1] https://buildd.debian.org/~luk/status/package.php?p=diagnostics
 
Old 02-02-2010, 08:45 AM
Reinhard Tartler
 
Default dpkg-gensymbols and C++ (once again)

On Di, Feb 02, 2010 at 10:04:04 (CET), Michael Tautschnig wrote:

> I guess the facilities to mangle/demangle are there, I just don't know
> whether they are accessible from the command line.

cf. c++filt(1)

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-02-2010, 09:41 AM
Raphael Hertzog
 
Default dpkg-gensymbols and C++ (once again)

On Tue, 02 Feb 2010, Michael Tautschnig wrote:
> Couldn't the following be implemented, maybe as some C++ mode of dpkg-gensymbols?
> - Instead of mangled symbol names, source packages should ship demangled symbol
> files. This way, package maintainers could truly inspect those lists of
> symbols and maintain them in a sane way (like manually adding symbols as the
> API evolves). The symbol names would remain independent of the architecture
> and sorted in some logical way (i.e., by C++ namespace and class names),
> unintended symbols as part of those lists would become obvious, etc.

The next version of dpkg will support this. See
http://bugs.debian.org/563752

> - Pending realizability using g++ or the like, these lists are converted to
> their architecture-specific variants consisting of mangled names by
> dpkg-gensymbols.

Note that the mangled name is what constitutes the ABI. So when the
compiler/build environment changes the mangling, the ABI is broken even if
the package generation is able to find a new match for the demangled
symbol (this happened recently for armel with gcc 4.4).

Cheers,
--
RaphaŽl Hertzog


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 02:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org