On Fri, 11 Oct 2013 09:50:08 -0700 Francisco Jerez <curroje...@riseup.net> 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 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
