Hi Gabriel, you wrote:
> | >>> On the other hand if your native compiler is GCC and your system was > | >>> not configured with that setting, then you may get into trouble -- > | >>> since you'll be mixing translation units with different ABIs. > | >> > | >> Furthermore, that sounds like a workaround. Isn't it still a > | >> compiler bug that it doesn't work without -fabi-version=0? > | > > | >No, it's correctly fixed, but since it's a fix that breaks ABI, the > | >version number was bumbed. By default, GCC 3.3 uses the GCC 3.2 ABI. > | >If you want to > | >activate the new version, you have to explicitally say so. > | >"-fabi-version=0" always selects the last version of the ABI. > | > | So are you are saying we should add "-fabi-version=0"? > > If you do that unconditionally, you may get ABI incompatible > libraries/programs compared to what your system come with. > > The default ABI version for GCC-3.3.x is 1. You might want to set it > to 2 and see what happens (for GCC-3.3.x) -- some bugs are fixed in > -fabi-version=2. > > > This whole thing (-fabi-version) is messy. It is what one gets by > taking users for beta testers ;-) That's not the whole story. When testing with GCC 3.3.1 prerelease I noticed that setting -fabi-version isn't necessary anymore. So I filed a bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11812, which immediately got closed ;-). The subsequent discussion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11105 leads me to believe that GCC 3.3 was too conservative w.r.t. ABI compatibility. Due to this and the fact that there's been another bug in GCC 3.3 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11198) which manifests when using ublas, I tend to advise against using GCC 3.3 for ublas. Thanks, Joerg _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost