On Sun, 2013-10-13 at 12:36 -0700, Ian Romanick wrote:
> On 10/13/2013 10:52 AM, Alexander von Gluck IV wrote:
> > * As discussed on the mailing list,
> > forced no-rtti breaks C++ public
> > API's such as the Haiku C++ libGL.so
> > * -fno-rtti *can* be still set however
> > instead of blindly forcing -fno-rtti,
> > we can rely on the llvm-config
> > --cppflags output.
>
> Does this means that builds that don't need LLVM will have RTTI (i.e.,
> -fno-rtti will not be used)?
This is actually currently how it operates. Mesa only gets forced
-fno-rtti when LLVM >= 3.2 is installed (further showing how odd this
current design is)
Current Design:
* LLVM not installed: RTTI enabled
* LLVM >= 3.2 installed: RTTI always disabled
(reguardless if LLVM had RTTI enabled)
* LLVM < 3.2 installed: Mesa mimics LLVM's rtti support status
llvm-config --cppflags
New design after patch
* LLVM not installed: RTTI enabled
* LLVM installed: Mesa mimics LLVM's rtti support status through
llvm-config --cppflags
Adding an extra bit of code to force -fno-rtti on non-public C++ abi's
(aka everything else) could be done, however we are once again throwing
in risk of mixing rtti and non-rtti code. ( I think the LLVM 3.2 check
came from the fact that LLVM 3.2 was the first release that dropped the
need for rtti.)
> It seems like if Haiku needs RTTI, we should enable RTTI only on Haiku.
> Am I missing something?
We could, however what is the point? As previously mentioned, mixing
RTTI and non-RTTI code could result in broken binaries on some platforms
and the performance impact is almost null on current systems. Matching
the LLVM rtti status seems like the most logical solution.
If we did go the route of leaving rtti enabled only for C++ facing
ABI's, how would we verify and remove the -fno-rtti flag from
llvm-config --cppflags in scons and automake? (i'm honestly not sure
here)
-- Alex
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
