Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On Tuesday 05 September 2006 11:34, Dirk Eddelbuettel wrote:
> On 5 September 2006 at 18:41, Luigi Ballabio wrote:
> | On Sep 3, 2006, at 5:57 PM, Dirk Eddelbuettel wrote:
> | > | s/small/self-contained/ then. Do you have some example where the
> | > | linking process of some c++ files takes ages, without linking them
> | > | against some external library? That would make things much easier
> | > | imho.
> | >
> | > I agree. But as I am unsure excactly what part in the area of
> | > templates and
> | > static initialization (or some variant thereof) causes this, I have to
> | > defer
> | > to Luigi.
> | >
> | > But yes, a smaller self-contained testcase would obviously help our
> | > case.
> |
> | Dirk,
> | I'm a bit out of context here. Are we talking about link times, or
> | about the link error in Etch?
>
> Link times. [ The 'link error in Etch' was something we first saw on hppa,
> and later noticed as a general problem -- but which is fixed in recent g++
> versions. ]
>
> Are you aware of anything we could turn in as a self-contained example?
> Without an example, the g++ authors will have a hard time tuning this.
>
> As I say it, build time for QL are way up relative to g++ 4.0; linking
> alone for the small-ish RQuantLib is now over 8 minutes. John seconded
> this observation based on a different code base he is working on.
>
> Do you still have a Debian box you use for development?
>
> Dirk
To follow-up on my experiences with g++-4.1 code and extremely slow link
times, I did a chroot and pulled in old versions of g++-4.1 and binutils from
snapshot.debian.net to build my big c++ application.
Here is a table with the following results:
Date g++-4.1 binutils Status
4-30-06 4.1.0-1+b1 2.16.1cvs20060413-1 fast link
5-30-06 4.1.0-4 2.16.1cvs20060413-1 fast link
5-30-06 4.1.0-4 2.17-1 slow link
6-30-06 4.1.1-5 2.16.1cvs20060413-1 fast link
6-30-06 4.1.1-5 2.17-1 slow link
The date column is for the day used to pull in g++-4.1 and binutils with the
the version shown in the other columns. The fast link represents something
on the order of several seconds, whereas slow link represents on the order of
15 minutes.
It is clear that the problem with slow linking comes from binutils version
2.17-1 (and greater) and not g++-4.1. There is a current binutils bug
report -- bug 3111 that seems to correlate with my experiences and Dirk's.
I will follow-up with binutils folks on this problem.
Dirk -- could you try and see if downgrading binutils to something less than
2.17-1 restores saner link times?
John Schmidt
Reply to: