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 <johannesoberm...@gmx.de> writes: > > > > > Am Dienstag, 15. Oktober 2013, 12:19:40 schrieben Sie: > > >> On Tue, 15 Oct 2013 17:04:26 +0200 > > >> Johannes Obermayr <johannesoberm...@gmx.de> wrote: > > >> > Am Montag, 14. Oktober 2013, 16:57:20 schrieb Francisco Jerez: > > >> > > Alexander von Gluck IV <kallis...@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 <curroje...@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 ... > > 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 > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
