similar to: [llvm-3.8.1] /usr/bin/objcopy: unrecognized option '--extract-dwo'

Hi, unfortunately, my build somehow hangs when linking clang binary and my system is in an unusable state. My toolchain is clang-3.8, gold-1.11 and LLVMgold.so from binutils v2.26.1 (both selfmade) and LTO-flag is enabled. My buildsystem uses cmake-3.6.0 and ninja-1.7.1 (both prebuilt). I have 52 last steps left in my 3rd build. My Linux-kernel is v3.13.0-92 from official Ubuntu repositories.

How big is your project? LTO eats RAM even faster than chrome. For example linking clang with LTO could take 16GB of ram. Have you tried using LTO on your project on that machine, or is it your first time? Piotr On Sat, Jul 23, 2016 at 2:42 AM, Sedat Dilek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jul 21, 2016 at 12:01 PM, Sedat Dilek <sedat.dilek at

> On Jul 23, 2016, at 1:53 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Jul 23, 2016 at 7:48 PM, Piotr Padlewski <prazek at google.com <mailto:prazek at google.com>> wrote: >> How big is your project? >> LTO eats RAM even faster than chrome. For example linking clang with LTO >>

Please have a look at the dedicated mailing list: http://lists.llvm.org/pipermail/llvm-branch-commits/ Please wait for the official release to happen, you will then find tarballs on llvm.org. They will also contain correct version strings, though I haven't yet tried building from the SVN branches directly. Maybe you need to use the SVN tags, $ clang --version currently gives me "clang

The source tarball for clang-tools-extra-3.9.0.src.tar.xz is also missing as well from http://llvm.org/releases/3.8.1/. Jack On Tue, Jul 12, 2016 at 7:34 AM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > There is no compiler-rt v3.8.1 source tarball available on > <http://llvm.org/releases/3.8.1/>. > > - Sedat - > > On Mon, Jun 27, 2016 at

On Mon, Jun 27, 2016 at 9:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >>>> What you're probably missing is that 3.8.1 is made in release_38 >>>> branch. So, everything is there and already mirrored. >>>> >>>> Source tarballs will be available upon the release. >>> Which are just coming, now that final has been

On Mon, Jun 27, 2016 at 9:39 AM, Hahnfeld, Jonas <Hahnfeld at itc.rwth-aachen.de> wrote: > Please have a look at the dedicated mailing list: > http://lists.llvm.org/pipermail/llvm-branch-commits/ > OK, I clicked the offline version of that ML on the main-page of <llvm.org>, so I knew of it. Anyway, I think most people use Git these days. > Please wait for the official

>>> What you're probably missing is that 3.8.1 is made in release_38 >>> branch. So, everything is there and already mirrored. >>> >>> Source tarballs will be available upon the release. >> Which are just coming, now that final has been tested successfully. :) >> They'll be announced in the list and available here: >>

Hi Tom, Hi Anton, the first I had in mind was... "Another (LLVM/CLang) realease - a new drama!" ( See Byron Katie "The work". ) I know SVN is your 1st development platform. Personally, I prefer Git and use the LLVM/Clang mirrors on GitHub. Unfortunately, I am missing a "release_381" branch at all on the GitHub repositories. I looked through the llvm-commits [1]

On Mon, Jun 27, 2016 at 12:14 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 27 June 2016 at 07:00, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> Building with CMake sets the version-string correct whereas using >> autotools as build-system does not. > > Hi Sedat, > > This was reported earlier and it's unfortunate, but we don't support

On 26 June 2016 at 13:31, Anton Korobeynikov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What you're probably missing is that 3.8.1 is made in release_38 > branch. So, everything is there and already mirrored. > > Source tarballs will be available upon the release. Which are just coming, now that final has been tested successfully. :) They'll be announced in the

> Can you answer my question on how to set the version-string correct > when generating tarballs out of the release_38 Git branch? > ( I generated source-tarballs out of my local Git repositories, see below. ) [ llvm.src/CMakeLists.txt ] ... if(NOT DEFINED LLVM_VERSION_MAJOR) set(LLVM_VERSION_MAJOR 3) endif() if(NOT DEFINED LLVM_VERSION_MINOR) set(LLVM_VERSION_MINOR 8) endif() if(NOT

On Mon, Jun 27, 2016 at 10:16 AM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Jun 27, 2016 at 12:14 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 27 June 2016 at 07:00, Sedat Dilek <sedat.dilek at gmail.com> wrote: >>> Building with CMake sets the version-string correct whereas using >>> autotools as build-system

On Wed, Mar 7, 2018 at 9:56 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Zach! > > I've been thinking a bit about this for a while now and I'm still of two > opinions: > > On Wed, Mar 7, 2018 at 9:21 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Currently llvm-objcopy only supports ELF

Hi, It's not clear to me what you mean by CLI "subcommands". Would you mind giving a brief example? Up to now, we've been trying to keep llvm-objcopy as close as possible to GNU objcopy, to make transitioning between them easier (I'm thinking in particular things like DWO generation). There are a small number of edge cases/unusual behaviours that we have chosen not to

On 27 June 2016 at 07:00, Sedat Dilek <sedat.dilek at gmail.com> wrote: > Building with CMake sets the version-string correct whereas using > autotools as build-system does not. Hi Sedat, This was reported earlier and it's unfortunate, but we don't support autotools build any more. The official releases are made using CMake and most of the buildbots are using it. Feel free

I had only a quick view on the blog-texts. It might be that a CLANG generated with LTO/PGO speeds up the build. Can you confirm this? Can you confirm binutils-gold speed up the build? Has LLVM an own linker? Can be used? Speedup the build? Yesterday night I loooked through available CMAKE/LLVM variables... ### GOLD # CMAKE_LINKER:FILEPATH=/usr/bin/ld #

LLVM already implements its own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build

Hey everyone, Sorry to jump in on this so late. My two cents is that it should remain GNU objoppy compatible most likely. It was always vaguely a desire to have command line compatibility but it has turned out over time that this is actually a crucial feature and should be one of the top priorities. You can't just go into a giant build system and swap out all the uses of GNU objcopy with

Hi James, Thank you for the comments. >I think we're not terribly far from that ideal, now, for ELF. Maybe only these three things need to be done? -- >  1. Teach lld how to emit a separated debuginfo output file directly, without requiring an objcopy step. >  2. Integrate DWARFLinker into lld. >  3. Create a new tool which takes the separated debuginfo and DWO/DWP files