[Mesa-dev] [PATCH] build: remove forced -fno-rtti

[Alexander von Gluck]

On Tue, 2013-10-15 at 15:05 -0700, Francisco Jerez wrote:
> Johannes Obermayr <johannesobermayr at gmx.de> writes:
> 
> > Am Dienstag, 15. Oktober 2013, 12:19:40 schrieben Sie:
> >> On Tue, 15 Oct 2013 17:04:26 +0200
> >> Johannes Obermayr <johannesobermayr at gmx.de> wrote:
> >> > Am Montag, 14. Oktober 2013, 16:57:20 schrieb Francisco Jerez:
> >> > > Alexander von Gluck IV <kallisti5 at unixzen.com> writes:
> >> > > 
> >> > > > * 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.
> >> > > >   If the system llvm is built without
> >> > > >   rtti (default), the no-rtti flag will be
> >> > > >   present in llvm-config --cppflags
> >> > > >   (which we pick up on)
> >> > > >   If llvm is built with rtti
> >> > > >   (REQUIRES_RTTI=1), then -fno-rtti is
> >> > > >   removed from llvm-config --cppflags.
> >> > > > * We could selectively add / remove rtti
> >> > > >   from various components, however mixing
> >> > > >   rtti and non-rtti code is tricky and
> >> > > >   could introduce bugs.
> >> > > > * This needs impact tested.
> >> > > 
> >> > > This looks like the right thing to do to me,
> >> > > 
> >> > > Reviewed-by: Francisco Jerez <currojerez at riseup.net>
> >> > > 
> >> > > Thanks.
> >> > 
> >> > ATM NACK because llvm-config doesn't output required -fno-rtti:
> >> > 
> >> > cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr -DLLVM_LIBDIR_SUFFIX=64 '-DLLVM_TARGETS_TO_BUILD=CppBackend;NVPTX;R600;X86;XCore' -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_TIMESTAMPS=OFF -DLLVM_ENABLE_FFI=ON -DLLVM_USE_OPROFILE=ON -DLLVM_BUILD_TESTS=OFF -DLLVM_INCLUDE_TESTS=OFF -DLLVM_BUILD_EXAMPLES=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_BUILD_TOOLS=ON -DLLVM_INCLUDE_TOOLS=ON -DLLVM_WC_REVISION=192557
> >> > 
> >> > $ llvm-config --cppflags
> >> > -I/usr/include    -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> >> > $ llvm-config --cxxflags
> >> > -I/usr/include -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -O2 -g -DNDEBUG  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> >> > $ llvm-config --cflags
> >> > -I/usr/include -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -O2 -g -DNDEBUG  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> >> > 
> >> > [  576s]   CXXLD    libgallium.la
> >> > [  579s] gallivm/.libs/lp_bld_debug.o:(.data.rel.ro._ZTI17raw_debug_ostream[_ZTI17raw_debug_ostream]+0x10): undefined reference to `typeinfo for llvm::raw_ostream'
> >> > [  579s] gallivm/.libs/lp_bld_debug.o:(.data.rel.ro._ZTIN4llvm14format_object1ImEE[_ZTIN4llvm14format_object1ImEE]+0x10): undefined reference to `typeinfo for llvm::format_object_base'
> >> > [  579s] gallivm/.libs/lp_bld_debug.o:(.data.rel.ro._ZTI18BufferMemoryObject[_ZTI18BufferMemoryObject]+0x10): undefined reference to `typeinfo for llvm::MemoryObject'
> >> > 
> >> > Please revert commit ce8eadb!
> >> 
> >> Please let me know if the patch I sent to the mailing list fixes it for you. If not, i'll revert the change to be reworked.
> >> As a side node, what version of LLVM are you running on what distro?
> >> It is *really* strange that you're seeing those rtti bugs while llvm-config --cxxflags doesn't include -fno-rtti.
> >> 
> >
> > No. It doesn't help.
> >
> > It is not strange because LLVM's CMake build system is buggy:
> >
> > Sth. like 
> >
> >   # Set common compiler options:
> >   if( NOT LLVM_REQUIRES_EH )
> >     if( LLVM_COMPILER_IS_GCC_COMPATIBLE )
> >       add_definitions( -fno-exceptions )
> >     elseif( MSVC )
> >       llvm_replace_compiler_option(CMAKE_CXX_FLAGS "/EHsc" "/EHs-c-")
> >       add_definitions( /D_HAS_EXCEPTIONS=0 )
> >     endif()
> >   endif()
> >   if( NOT LLVM_REQUIRES_RTTI )
> >     if( LLVM_COMPILER_IS_GCC_COMPATIBLE )
> >       llvm_replace_compiler_option(CMAKE_CXX_FLAGS "-frtti" "-fno-rtti")
> >     elseif( MSVC )
> >       llvm_replace_compiler_option(CMAKE_CXX_FLAGS "/GR" "/GR-")
> >     endif()
> >   endif()
> >
> > from function(llvm_process_sources OUT_VAR) from cmake/modules/LLVMProcessSources.cmake must be in tools/llvm-config/CMakeLists.txt
> >
> > I won't send a patch to LLVM because it is like on Mesa and I must run after people for months to get bug/build fixes not pushed.[1] Complaining and let others work is much much ...
> >
> > [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/187516.html (almost 4 months ...)
> 
> 
> Independently from that, you may have hit a bug in your distribution,
> shipping LLVM built with '-fno-rtti' violates LLVM's packaging
> guidelines [2].
> 
> [2] http://llvm.org/docs/Packaging.html#c-features

Eh, the llvm folks in irc were complaining about that packaging comment.
They are all for having RTTI disabled. Either way, my goal was to have
rtti and non-rtti builds working :-)

The fact that Johannes's llvm was built with -fno-rtti and doesn't
report it in llvm-config it is the real issue. We need more info here so
I can try to reproduce it.

I have a patch on the ML to fix the scons rtti build issue (unrelated).
If no one pushes back in the next few hours i'm going to go ahead and
push it as it fixes a build breakage.

 -- Alex