similar to: [LLVMdev] llvm trunk build failed in cmake_install.cmake on ARM platform

We try to change cmake's behaviour so that it uses $ORIGIN in the rpath, making the binaries relocatable. That might be falling in here for some reason. Sent from my iPhone > On Feb 12, 2014, at 11:07, Brad King <brad.king at kitware.com> wrote: > >> On 02/12/2014 08:08 AM, Mathias Bauer wrote: >> Hi dear list, >> >> I tried to build llvm+clang on an

> that CMake is trying to update the installed binary file's > RPATH to contain the $ORIGIN/../lib value. It complains > that no RPATH field at all is found in the file. The linker > may be dropping it for some reason, which is why I asked > Mathias to try: Btw, an awesome way to fix this would be to set rpath to $ORIGIN/../lib during the link itself. That way it doesn't

A couple of llvm sub-projects have been failing to build for me for a while (compiler-rt asan and util/unittests, at least). It turns out to be due to the fact that some paths on my system include spaces and other special characters, but the the build.ninja file was not generated with correctly quoted strings. Specifically I'm on OS X and the command is setting -isysroot to a location inside

Hi, everyone. I'm trying to build LLVM myself because the page I was linked to with the links to pre-built binaries doesn't have a passing WASM build of LLVM. Or at least didn't when I last checked there. With that being said, though, when I tried to build INSTALL.vcxproj, I got the error mentioned in the title of this message. The full error message is in the attached text file.

LLVM currently has CMake code to try to detect the various options needed to compile with C++11 support that has been around since prior to the CMake version bump. One of the nicer features that came with the newer required CMake version is that very thing. Rather than try to discern this yourself CMake has the CXX_STANDARD and CXX_STANDARD_REQUIRED target properties. If set appropriately on a

It was just brought to my attention that the RPATH configuration isn't uniform among the libraries produced by the release. Some use $ORIGIN../lib/ and others have none. Is this by design? It seems like it might be ideal for all of them to be configured the same way. If that makes sense I'll create a corresponding feature request. $ for f in

Isn't libc++.so dependent on libc++abi.so? On Mon, Mar 5, 2018 at 10:30 AM, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote: > From what I can see all of the libraries without RPATH are runtime > libraries that are used by binaries compiled with Clang. I think they don't > have a dependency on other libraries in that directory, so what would be > the advantage of having

From what I can see all of the libraries without RPATH are runtime libraries that are used by binaries compiled with Clang. I think they don't have a dependency on other libraries in that directory, so what would be the advantage of having RPATH set on them? Regards, Jonas Am 2018-03-05 17:23, schrieb Brian Cain via llvm-dev: > It was just brought to my attention that the RPATH

libc++.so should be a linker script that automatically pulls in libc++abi (see "Failed to read file header" in your output). And IIRC libc++abi is only one possible implementation that may be used by libc++, but I'm no expert here... Am 2018-03-05 17:33, schrieb Brian Cain: > Isn't libc++.so dependent on libc++abi.so? > > On Mon, Mar 5, 2018 at 10:30 AM, Jonas

Uploaded ubuntu, SLES11, SLES12 binaries. 4907dbd37f4e5265a2f1252d9d7b5e5b0a9c0ec1 clang+llvm-6.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz 360b26fcd9eafe5ca9c4baa89c38339bc587c094 clang+llvm-6.0.0-x86_64-linux-sles11.3.tar.xz ce525cf949ef86409bc3f4f492035225989eecfd clang+llvm-6.0.0-x86_64-linux-sles12.2.tar.xz On Fri, Mar 2, 2018 at 6:17 AM, Hans Wennborg via Release-testers < release-testers

Dear testers, The final version of 6.0.0 has just been tagged from the branch after r326550. It has the same contents as -rc3 modulo release notes and one small x86 fix (r326393). Please build the final binaries and upload to the sftp. For those following along: this means llvm-6.0.0 is complete, but it will take a few days to get all the tarballs ready and published on the web page. I will

On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > Please note that it makes a lot of sense to built compiler-rt (and sanitizers) with just-built > Clang. In fact, even though we should support building it with another compilers (gcc, MSVC), > using just-built-Clang should be a default scenario, like it is in configure+make build. This is possible with CMake using the ExternalProject

Answer inline. On Sun, Dec 30, 2018 at 12:59 PM James <list at xdrv.co.uk> wrote: > On 29/12/2018 13:49, Pierluigi Frullani wrote: > > > My version is 2.2.13 ( it was the last one, at the time of the first > > server setup ). > > 2.2.13 is from around May 2014. It worked but I can't see why you > wouldn't switch to the latest 2.3.4. (You might be seeing

Well, I updated to cmake 2.8.12.2 but the result of changing that COMPILE_FLAGS to COMPILE_OPTIONS is that quotes are applied incorrectly: quotes are added surrounding the entire set of flags rather than around each individual item in the list. Obviously the build doesn't work (with the compiler looking for files named " -m64 ... ") but checking the relevant build command in

On 2 Feb 2014, at 17:42, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> 6) If you create a proper config file, then you can populate it with >> IMPORTED targets and use it in clang. IMPORTED targets record dependencies >> and usage requirements (when you start requiring CMake 2.8.9+ at least) >> properly. >> >>

Hi all, I've just upgraded my old Solaris 10 update 8 to Solaris 10 update 11 with the latest patches, but after the reboot with the new update I'm having a lot of problems with dovecot. My version is 2.2.13 ( it was the last one, at the time of the first server setup ). I have seen that ( it seems ) the new solaris don't honour the LD_LIBRARY_PATH. The first error was a

On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: > ldd your_built_clang | grep libstdc++ > chrpath -l your_built_clang Hmm, where "your_built_clang" should be the actual failing executable: /home/evansl/dwnlds/llvm/3.5rc1/build/Release+Asserts/bin/llvm-tblgen Ben

On 07/30/2014 10:06 AM, Larry Evans wrote: > On 07/30/2014 12:35 AM, Ben Pope wrote: >> On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: >> >>> ldd your_built_clang | grep libstdc++ >>> chrpath -l your_built_clang >> >> Hmm, where "your_built_clang" should be the actual failing executable: >>

Hi Lang, I am on Ubuntu 14.04. I am building ToT: llvm, clang, polly, lld, compiler-rt, libcxx, libcxxabi. The build compiler is: clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04 The failures show up during "make check-all". My cmake command was: cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/w/c/org -DLLVM_TARGETS_TO_BUILD:STRING=all

I have just committed support to llvm-ar for creating thin archives. The idea of thin archives is that they contain just the symbol table and the path to find the original .o files. By locally making thin archives the default I was able to build llvm+lld+clang with them. The total size of the .a files goes from 181,658,164 to 7,116,900 bytes. Is there any way to do that with cmake without having