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. 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... Thanks. > --Ken
pgp7qXWeGtZYz.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
