[Mesa-dev] RFC: LLVM, -fno-rtti, and Haiku
currojerez at riseup.net
Fri Oct 11 20:45:18 CEST 2013
Kenneth Graunke <kenneth at whitecape.org> writes:
> On 10/11/2013 09:50 AM, Francisco Jerez wrote:
>> Kenneth Graunke <kenneth at 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:
>>>> My solutions are either removing the forced -fno-rtti, or wrapping it
>>>> with a platform != 'Haiku'
>>>> -- 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.
> 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
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 229 bytes
Desc: not available
More information about the mesa-dev