similar to: rpmbuild dwz error

Am 21.08.2015 um 21:08 schrieb ????????? ???????? <nevis2us at infoline.su>: >> On CentOS 7, I'm building a large C++ package with rpmbuild. Arachne >> (https://www.broadinstitute.org/crd/wiki/index.php/Arachne_Main_Page). >> During the debuginfo extraction stage, I get the following error: >> + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz

On 21/08/15 22:46, Andrew Neuschwander wrote: > On 08/21/2015 02:04 PM, Leon Fauster wrote: >> Am 21.08.2015 um 21:08 schrieb ????????? ???????? <nevis2us at infoline.su>: >>>> On CentOS 7, I'm building a large C++ package with rpmbuild. Arachne >>>> (https://www.broadinstitute.org/crd/wiki/index.php/Arachne_Main_Page). >>>> During the

On 08/21/2015 02:04 PM, Leon Fauster wrote: > Am 21.08.2015 um 21:08 schrieb ????????? ???????? <nevis2us at infoline.su>: >>> On CentOS 7, I'm building a large C++ package with rpmbuild. Arachne >>> (https://www.broadinstitute.org/crd/wiki/index.php/Arachne_Main_Page). >>> During the debuginfo extraction stage, I get the following error: >>> +

> On CentOS 7, I'm building a large C++ package with rpmbuild. Arachne > (https://www.broadinstitute.org/crd/wiki/index.php/Arachne_Main_Page). > > During the debuginfo extraction stage, I get the following error: > > + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz > --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 >

On 01.09.2020 20:07, David Blaikie wrote: > Fair enough - thanks for clarifying the differences! (I'd still lean a > bit towards this being dwz-esque, as you say "an extension of classic dwz" I doubt a little about "llvm-dwz" since it might confuse people who would expect exactly the same behavior. But if we think of it as "an extension of classic dwz" and

On 02.09.2020 21:44, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 01.09.2020 20:07, David Blaikie wrote: >> Fair enough - thanks for clarifying the differences! (I'd still >> lean a bit towards this being dwz-esque, as you say "an

On 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

On 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>

We're getting the below errors about once a day on a system we're trying to set up with RedHat 7.3. This has happened to multiple filesystems on multiple physical and logical disks (basically we've got 4 drives as 2 sets of RAID 1 arrays, details below). Until a week ago, this box was a high-volume IMAP server running RedHat 6.2 with uptimes in the 200-day range, so I don't

Currently, LLVM's DWARF parser keeps Compile Units and Type Units on separate lists, basically organizing them by ELF section. This works okay for DWARF v4, because Type Units are in .debug_types (possibly in individual COMDATs) and everything else is in the .debug_info section (without COMDATs). The two lists conveniently can be templated/typed with DWARFTypeUnit and DWARFCompileUnit. In

Debuginfo and linker folks, we (AccessSoftek) would like to suggest a proposal for removing obsolete debug info. If you find it useful we will be happy to work on improving it. Thank you for any opinions and suggestions. Alexey.     Currently when the linker does garbage collection a lot of abandoned debug info is left behind (see Appendix A for documentation). Besides inflated debug info size,

Hi, I'm hitting a strange problem where pdf plots that I'm trying to make are blank, only when produced from within a loop. The pdf contains 0 page. I've narrowed the problem to this minimal script that invariably produces an empty pdf with my setup: pdf("/local/scratch/1.pdf", width=8, height=8) for (k in 1) { wireframe(volcano) } dev.off() The odd thing is that

On Monday 11 March 2019 14:28:38 Pete Biggs wrote: > > However, as I went for bigger modules, anything that had dependences > > were then failing as the dependencie were installed OK but then did not > > appear to be available. > A number of things you can do. The sort of recommended way is to > package the perl modules into an RPM and install them that way (so that >

I try to compile samba-2.07 in a separate directory and it fails with : Linking bin/smbd ld: 0711-934 SEVERE ERROR: Cannot create the output file: bin/smbd ld:open() A file or directory in the path name does not exist. collect2: ld returned 12 exit status gnumake: *** [bin/smbd] Error 1 because the directory `bin' does not exist in my build directory; the

Dear all, I am writing a vignette that requires a file which I am not allowed to distribute, but which the user can easily download manually. Moreover, it is not possible to download this file automatically from R: downloading requires a (free) registration that seems to work only through a browser. (I'm talking here about the MSigDB from the Broad Institute,

$ free -g total used free shared buff/cache available Mem: 376 149 20 1 207 225 Swap: 3 0 3 Too small swap size for a 72-core login machine? On Sun, Mar 29, 2020 at 4:28 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Enable threads is for building llvm with

Hi, My configuration is below: cmake -GNinja -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_THREADS=OFF -DLLVM_ENABLE_LIBCXX=ON -DCMAKE_BUILD_TYPE=Release -DGCC_INSTALL_PREFIX=/home/usr4/c74014i/opt/gcc-7.5.0/ -DLIBOMPTARGET_ENABLE_DEBUG=ON -DCMAKE_INSTALL_PREFIX=$HOME/opt/clang/${today} -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="" -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=""

On 2020-03-29, Nemanja Ivanovic via llvm-dev wrote: >Glad you got it working. >My suggestion about LLVM_ENABLE_THREADS didn't work because you didn't >apply it when building the build linker. > >When you don't have the ability to rebuild the build compiler, this doesn't >apply. In those cases, I end up doing a dirty hack where I use a wrapper >script with

That is slowing down the build visibly, for the speed I should stick with ld at the moment. On Sun, Mar 29, 2020 at 4:42 AM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > Would `taskset -c 0-3 ninja check-all -j4` work? > > > > *De :* Itaru Kitayama <itaru.kitayama at gmail.com> > *Envoyé :* March 28, 2020 3:37 PM > *À :* Alex Brachet-Mialot

Good news, I was able to use up to 37 cores for LLVM build with LLD. The build speed, did not measure precisely though, is comparable to the build with GNU ld case. Thank you all for your help! On Sun, Mar 29, 2020 at 5:04 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes unfortunately that would limit you to 4 cores. > > There’s no easy way to use lld with