[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of C++ symbols experience



Russ Allbery <rra@debian.org> writes:

> However, it does have some problems, some obvious, and some more subtle.
> Here's a list of the issues that I see:

> 1. It feels like this symbols file is still likely to be fragile.  While
>    pkg-kde-tools detects a *lot* of template instances and marks them
>    optional, I was still seeing a lot of "leaked" symbols from other C++
>    libraries that my package build-depends on, and which I suspect may
>    also disappear.  There's also the problem of optimizers eliminating
>    some things that are inlined; for example, that appears to be the
>    variation that my package sees on arm.  And for a substantial C++
>    library, the symbols file is HUGE.  Over 12,000 lines for one of my
>    libraries.  It's kind of scary to think of how many fragility landmines
>    are buried under there.

And indeed, this process has already broken.  Take a look at:

https://buildd.debian.org/status/logs.php?pkg=opensaml2&arch=ia64&ver=2.4.3-3

and you'll see that the build has already failed, despite the fact that
the symbols were already synced on ia64.  But the first time, when 2.4.3-2
built, it built on caballero, which has g++ 4:4.6.2-1 installed.  When I
uploaded the version with the merged symbols template, it built on alkman,
which has 4:4.6.1-3 installed.  Look at all the changes!  There are *tons*
of symbols that have now appeared when built with the older compiler.
Spot-checking, they appear to be small inline functions; it looks like
4.6.2 optimizes them out of existence, but 4.6.1 doesn't.

I can go through and apply this symbol change as well, or be more
aggressive and mark anything that only turned up on some architectures as
optional under the theory that it will be a similar case, but I don't
think this is viable.  This is *way* fragile if patch releases of the
compiler cause huge swings in the symbols that show up.

I'm not sure this mechanism is actually usable unless upstream is using
visibility and export controls in the library; I'm going to spend all my
time tweaking symbols that appear and disappear to avoid FTBFS.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: