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

Wed Oct 16 23:58:53 CEST 2013

On Wed, 2013-10-16 at 22:09 +0200, Johannes Obermayr wrote:
> Am Dienstag, 15. Oktober 2013, 17:22:54 schrieb 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.
> 
> Please read exactly what I wrote. I already provided all required information (LLVM_WC_REVISION, FLAGS, ...) together with a hint at puzzle's solution (Sth. like [...] from [...] must be in [...]).
> I hate to repeat permanently ...

Please read my original request.

"As a side node, what version of LLVM are you running on what distro?"

I still have no idea what version of LLVM you are running and what
distro you are using. I can't reproduce something if I know nothing on
the environment I have to reproduce it in.

We've seen no other complaints on this issue, so likely it is something
environmental on your end. (unless an older version of LLVM has an
issue... which is what i'm trying to figure out)

 -- Alex