On Fri, 2010-02-05 at 10:30 +0100, eric b wrote: > Hi, > > Le 5 févr. 10 à 10:15, Caolán McNamara a écrit : > > > On Fri, 2010-02-05 at 09:19 +0100, eric b wrote: > >>> Till now we have tested DEV300_m58 and DEV300_m60, the breakage > >>> took place in the latter but not the former one. > > > > And it was *definitely* the same compiler and tool chain used in > > both cases right ? And the error in question is ... > > > > Exactly : both tree on the same machine : rebuild comphelper with > DEV300_m57, and DEV300_m58 is ok. > > Starting m60 -> you have the issue,
Do we have logs of the exact gcc compile and link calls between "pass" and "fail". Perhaps sometime around there some -Bsymbolic changes went in, or some extra visibility flags (don't think so) were added which triggered the underlying foo. Though it might just have been that some method randomly got large or small enough to run through a different optimization path. mips uses the -Os opt (probably copied from the Intel one originally), which is one of the less travelled gcc optimization routes as -O2 is the typical optimization. Using -O2 is worth a shot as an experiment as well, as are turning off visibility. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
