similar to: [LLVMdev] CMake-generated llvm-config.

arrowdodger <6yearold at gmail.com> writes: > On Thu, Jan 27, 2011 at 3:50 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > >> How do they build their frontend? >> > They are running llvm-config. And it gives -pedantic, if it was generated by > CMake build. If i build LLVM with autoconf, then everything is fine. > > Here is output of llvm-config built by

arrowdodger <6yearold at gmail.com> writes: >> Here is output of llvm-config built by CMake: > >> ~/.local/llvm/bin/llvm-config --cflags >> -I/usr/home/arr/.local/llvm/include -O3 -DNDEBUG -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -Wall -W -Wno-unused-parameter -Wwrite-strings >> -pedantic -Wno-long-long >> > Note -pedantic here. Committed

Submitted r204593. On Sun, Mar 23, 2014 at 10:03 PM, Alexey Samsonov <samsonov at google.com>wrote: > Hi Dmitri, > > On Sat, Mar 22, 2014 at 11:50 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > >> Hello, >> >> It looks like compiler-rt CMake scripts don't take CMAKE_CXX_FLAGS >> into account. This is because clang_compile and

Hello, It looks like compiler-rt CMake scripts don't take CMAKE_CXX_FLAGS into account. This is because clang_compile and clang_link_shared functions call the newly-built compiler directly, and they don't add those flags. Using CMAKE_CXX_FLAGS is necessary on systems where the C++11-enabled libstdc++ is installed not in the default location. For example, the CentOS buildbot uses:

Hi Nico, Hans, Takumi, I made it to the bottom of the issue. Turns out that CMAKE_C_FLAGS=-m64 CMAKE_CXX_FLAGS=-m64 CMAKE_EXE_LINKER_FLAGS=/machine:x64 is enough to do a 64-bit build correctly with a 32-bit clang-cl (i.e. one that targets 32-bit by default). Hooray! The missing piece that I had to track down is why I would see `deps = msvc` stuff spewing onto my terminal, rather than consumed

arrowdodger <6yearold at gmail.com> writes: >> Or to say it with other words: patches welcome. > > So, how should i proceed? Make CMake-generated config to be identical to > autotools one? That would be a good thing. Please note that some checks are a bit tricky. A function that on platform A is on header foo.h on another platform may be on bar.h. Furthermore, cmake's

> On Dec 20, 2016, at 5:49 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ​Hi again, Teresa. > > Looks like I had forgotten to report back with success > when finally building 3.9.0 in ThinLTO linker mode > back in October. Sorry about that and thanks for > helping me out. I know how important it is to get > success reports as well, as a

Hello LLVM-DEV! Recently I think I found a bug in llvm's CMakeLists.(I use llvm 3.1svn and Clang 3.1) I follow the normal way to try to compile an application that utilize both clang and llvm: I ./autogen.sh it, ./configure it and make it. But the make fails. At last I found out the failure is because that the Makefile's CXXFLAGS does not contain -fno-rtti option which is needed by the

On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: >> [ brutal-snip ] >> ... >>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more >>>

On Jan 5, 2011, at 6:34 AM, Óscar Fuentes wrote: > arrowdodger <6yearold at gmail.com> writes: > >>> Or to say it with other words: patches welcome. >> >> So, how should i proceed? Make CMake-generated config to be identical to >> autotools one? > > That would be a good thing. > > Please note that some checks are a bit tricky. A function that

Also please note that there is a description of each option in the CMakeLists.txt :) llvm/trunk/CMakeLists.txt option(LLVM_ENABLE_MODULES "Compile with C++ modules enabled." OFF) option(LLVM_ENABLE_CXX1Y "Compile with C++1y enabled." OFF) option(LLVM_ENABLE_LIBCXX "Use libc++ if available." OFF) option(LLVM_ENABLE_LIBCXXABI "Use libc++abi when using

José Fonseca <jose.r.fonseca at gmail.com> writes: > Attached are two patches with MSVC build enchancements. > > They are quite trivial, but were necessary to correctly link LLVM > libraries with Mesa3D on Windows. [snip] > add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE ) > + add_llvm_definitions( -D_SECURE_SCL=0 ) With this setting the default LLVM build becomes

Hi Rafael, I looked at the code which you pushed a while ago to check for the gold linker. Code below: execute_process( COMMAND ${CMAKE_C_COMPILER} -Wl,--version OUTPUT_VARIABLE stdout ERROR_QUIET) if("${stdout}" MATCHES "GNU gold") set(LLVM_LINKER_IS_GOLD ON) endif() I was trying to build runtime libraries (compiler-rt)

I reacted as per my case. You need CFLAGS in order to what linker you might be using. In case of clang, you can use “-fuse-ld” to control the invocation of linker. In my opinion, it is not necessary to carry forward LDFLAGS unless you want to control specific parts of the linker. In my case, I have a cross compiler for ARM and I usually compile the code with Clang

As an aside, is there any reason for why C++-style comments were used in C files at all, or should they simply be replaced with the usual /* ... */ in accordance with pre-C99 standards? In the latter case, would there be any objection to it if I were to make a patch for this? While the change itself would be trivial, I don't yet have any experience with making patches, and so for that purpose

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

Hi Vitaly, This is the CMake command line I used: cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/stage2 \ -DCMAKE_C_COMPILER=$HOME/stage1/bin/clang \ -DCMAKE_CXX_COMPILER=$HOME/stage1/bin/clang++ \ -DCOMPILER_RT_BUILD_BUILTINS=off -DCOMPILER_RT_BUILD_PROFILE=on \ -DCOMPILER_RT_BUILD_SANITIZERS=on -DCOMPILER_RT_BUILD_XRAY=off \

I wish there was something like the line in config.log that would show the CMake command, but instead I can at least show you the CMakeCache files for my release build and asan build (attached to this email). No lld, so far as I know - believe I'm using gold at the moment for both builds. Did just reproduce this with a clean release build and a clean asanified build from that. Same errors. I

Ah! Think I figured it out -- it's rtti. When I build with -fno-rtti, the spurious symbol disappears. Blargh, that was complicated. I'm going to try an out-of-source cmake build now. So far this has been a soliloquy, hope it helps someone else. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Charles Jacobsen

Isn't there someone to help me with this issue? I'm very upset about this stupid problem which wasted the whole day. BTW, I can create JIT from main.cpp, but not in the required source file (runtime.cpp), so this is not about linking. Very weird. 2011/9/2 Semion Prihodko <semion.ababo at gmail.com> > I cannot call the constructor explicitly, because ForceJITLinking is a name