Re: Bug#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary
On Fri, 30 Apr 2004, Matthias Klose wrote:
> > Right now, I see four alternative solutions:
> > 1) Upload a new Debian package where -fno-exceptions is not turned on.
>
> If you change interfaces, you'll have at least change the package name
> and/or soname and recompile dependent packages.
I am not aware of a change in interface when turning off -fno-exception!
Is there one?
> > 2) Fix CLN by playing dirty tricks. For instance, printing the variable
> > erg's address in src/integer/output/cl_I_print.cc:30 seems to fix the
> > problem. It should be possible to somehow read that address without
> > any side-effect.
>
> preferred solution, unless
Seems feasible. Introducing the section
+#if (defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ < 4))
+ // workaround GCC 3.0.0-3.3.3 compiler bug (cf. Debian bug#246319)
+ static char dummy[40];
+ snprintf(dummy,40,"%d%x%x",need,&erg,erg.LSBptr);
+#endif
at line 30 of cl_I_print.cc seems to fix the problem. Yes, I have to
print all three variables. Any smaller subset doesn't seem to do the
trick. Scary, I would say.
> > 3) Fix GCC on the 3.3 branch. It would probably take me at least a full
> > day to distill a useful testcase, however. Likely more, if it turns
> > out to be a Heisenbug. And if this leads to a fix in the GCC 3.3
> > branch is more then doubtful, I guess.
>
> you are able to extract a reduced testcase. yes.
>
> > 4) Use Debian's gcc-3.4 [0], making that a requirment for depending
> > packages, too.
>
> Not really an option because of changes in the C++ ABI and libstdc++.
>
> > Soooo, what are the chances for gcc-3.4 hitting sarge as the default
> > compiler? In my experience, this is a much better compiler than 3.3.3, in
> > all respects, including reliability. The whole 3.3 series seems to be
> > having some problems. In another context, it has already been suggested
> > by GCC developers that the 3.3 branch may have taken place too early,
> > causing patches not beeing applied properly and so on [1].
>
> IMO no chance as the default compiler. Remember the time needed for
> the last C++ transition. Maybe as an option, if the runtime libraries
> built by 3.3 and 3.4 are compatible.
Okay, thanks for this assessment. The runtime libraries aren't
compatible, as far as I know. This is even manifest from the bump in the
library's soname: It's libstdc++.so.6 in GCC 3.4 vs. libstdc++.so.5 in
GCC 3.[23].
Cheers
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
Reply to: