[sword-devel] Xiphos FTBFS with GCC 5.0

[Karl Kleinpaste]

On 02/10/2015 01:25 AM, Matěj Cepl wrote:
>     xiphos-4.0.0-3.fc22.src.rpm
>       this package failed to build because the limit of the 
>       instantiation depth has been reached.
Considering that I have no environment in which to test this, it's not
very informative.  Is there a build log?

Absent a log I can see, I will make an educated guess, that this problem
occurs in modulecache.hh, because clang++ crashes on such a misguided
claim (with absurd/insane values, literally in the tens of thousands). 
The depth there is because the cache is instantiated as a layered series
of string- and int-keyed std::maps.

    // In precision order.
    typedef std::map < int, CacheVerse     > CacheChapter;
    typedef std::map < int, CacheChapter   > CacheBook;
    typedef std::map < int, CacheBook      > CacheTestament;
    typedef std::map < int, CacheTestament > CacheModule;

    // Index by module name => Cache for that module.
    typedef std::map < const std::string, CacheModule > CacheMap;

    // Textually:
    // CacheMap contains modules of testaments of books of chapters of
    // verses, subscriptable at any stage to get the subordinate content.

However I fail to see how this is a problem, considering that this is in
all honesty a rather bland use of nested maps, and only 5 deep.  Also,
the referenced message observes...

> These consist of either package bugs, or GCC bugs.

...and I am inclined to claim that they have a new bug to fix, because
this just shouldn't be a problem, and isn't a problem in gcc4.

Anyhow, I am making suppositions out of air about this; I need a log to
stare at, to see where the problem claimed actually occurred.

Is gcc5 intended to be mandatory in f22?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20150210/193826da/attachment.html>