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

Francisco Jerez currojerez at riseup.net
Wed Oct 16 00:05:39 CEST 2013


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


> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131015/41d86b57/attachment.pgp>


More information about the mesa-dev mailing list