On 10/11/2013 11:45 AM, Francisco Jerez wrote: > Kenneth Graunke <kenn...@whitecape.org> writes: > >> On 10/11/2013 09:50 AM, Francisco Jerez wrote: >>> Kenneth Graunke <kenn...@whitecape.org> writes: >>> >>>> On 10/10/2013 04:27 PM, Alexander von Gluck IV wrote: >>>>> >>>>> In llvm.py -fno-rtti is always a build flag if LLVM present >= 3.2 >>>>> >>>>> This breaks everything on our end (missing rtti related symbols) in our >>>>> C++ libGL.so as Haiku uses dynamic casts. >>>>> >>>>> We build our LLVM packages with rtti (REQUIRES_RTTI=1). >>>>> >>>>> Not 100% sure why we're forcing no-rtti if LLVM >= 3.2. >>>>> "llvm-config --cxxflags" should always show "-fno-rtti" if REQUIRES_RTTI=1 >>>>> wasn't set at build time. If REQUIRES_RTTI was set, -fno-rtti is removed >>>>> from the llvm-config cxxflags. >>>>> >>>>> It was originally added here: >>>>> http://cgit.freedesktop.org/mesa/mesa/commit/scons/llvm.py?id=d37ae642034bcaca39492c1eb75b029fb27ceffb >>>>> >>>>> My solutions are either removing the forced -fno-rtti, or wrapping it >>>>> with a platform != 'Haiku' >>>>> >>>>> Thoughts? >>>>> >>>>> -- Alex >>>> >>>> I would love to see us build with -fno-rtti for all Linux builds. I've >>>> been meaning to try that and measure the impact. >>>> >>> The -fno-rtti option is evil, it changes the C++ ABI in an incompatible >>> way. As you may have noticed from the build error, in some cases it's >>> impossible to link normal C++ object files with -fno-rtti object files >>> if the interface between them exposes polymorphic types. >>> >>> That's the reason why some LLVM versions require us to build the >>> interfacing module with -fno-rtti, and the same versions require us to >>> build *without* -fno-rtti if RTTI was enabled in the LLVM build, as >>> might be the case in Haiku and some Linux distributions. >>> >>> AFAICT the 'if' statement in scons/llvm.py:198 and the automake >>> conditional in configure.ac:1953 are broken and should probably be >>> removed. LLVM doesn't require -fno-rtti unless llvm-config says >>> otherwise, and if it still does in some case it's an llvm-config bug >>> that can probably be addressed differently. >>> >>> I don't think it's a good idea to enable -fno-rtti except for isolated >>> modules that can be guaranteed not to expose or use any C++ API. There >>> are legitimate uses of RTTI, and enabling -fno-rtti means that modules >>> that use it cannot talk to modules that don't. >>> >>> Thanks. >> >> Which would be fine for Mesa (except maybe on Haiku), since all of our >> usage of C++ is internal and we don't expose /any/ C++ API. Nor should we. >> >> It looks like Clover uses RTTI. Nothing else does, and I'd like to keep >> it that way. >> > > Clover has a legitimate reason to do so -- and it's not the only user > BTW, the nv50 compiler and 'src/gtest' seem to use it too. Anyway, even > if we don't use RTTI internally, building with -fno-rtti is a bad idea, > because it makes interfacing with other C++ projects extremely > difficult.
You mean LLVM? My point is that Mesa does *not* interface with other C++ projects. It's an OpenGL library that exposes a 100% C API. It doesn't make *sense* to interface with other C++ projects. > It can also cause problems in cases where we don't expose any C++ API > ourselves and we are mere users of some C++ library -- like the Haiku > system libraries or LLVM (IIRC even LLVM recommends distributions *not* > to use -fno-rtti in their builds because of the ABI issues). I don't > see the point of making our internal C++ ABI deliberately non-standard, > it's likely to give us more headaches for little or no benefit... If it's necessary for LLVM, then I guess that trumps the overhead of having to compile with RTTI. But I know even LLVM reimplemented dynamic_cast<> to avoid the cost of RTTI. Other than LLVM, I don't think we will ever depend on any C++ library. --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
