Kenneth Graunke <kenn...@whitecape.org> writes: > 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. > On a side note, it's always seemed quite funny to me that they did. The cost of run time type identification using typeid() is negligible on modern C++ compilers (including Clang), as it can be optimized out to a pointer comparison, and the cost of a dynamic_cast<> is comparable to the cost of a virtual function call in most cases.
I'm aware that this hasn't always been the case historically, but it's funny that they designed based on that as they were writing a compiler and they could've just fixed what was mostly an implementation issue... :) > Other than LLVM, I don't think we will ever depend on any C++ library. > > --Ken
pgp8PTcUCIM8w.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev