[Mesa-dev] RFC: LLVM, -fno-rtti, and Haiku

[Alexander von Gluck IV]

On Fri, 11 Oct 2013 09:50:08 -0700
Francisco Jerez <currojerez at riseup.net> 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:
> >> 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 fil
> 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.

That would solve my issues.  Do we need to do any kind of impact testing? I
haven't done much Mesa Linux development, so I'm not sure of the process.

 -- Alex