similar to: Proposal: Enable BUILD_SHARED_LIBS=ON by default for debug build.

Hi David, I assume you have a powerful machine. Our drive space is on network mounted machined by IT department. The machine is default Ubuntu setup with 8 cores. Shared build is showing huge advantage due to size reduction. I will try those two debug options to see how it works. Thanks, Yin From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Thursday, January 28, 2016

On Thu, Jan 28, 2016 at 3:06 PM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > > > On 1/28/16 4:00 PM, Yin Ma via cfe-dev wrote: > >> Hi David, >> >> I assume you have a powerful machine. Our drive space is on network >> mounted >> >> machined by IT department. The machine is default Ubuntu setup with 8 >> cores. >>

Hi Yin, I second David's words. I use shared libs myself on debug builds, but static builds with gold on a local disk is pretty feasible. Before I used gold, I had to have 16GB of RAM on my laptop, now I need less than 8GB for static builds. On 28 January 2016 at 23:58, Yin Ma via cfe-dev <cfe-dev at lists.llvm.org> wrote: > It is O.K. I just hope BUILD_SHARED_LIBS=ON is tested

>If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication. > >This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM. > >This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. >Though

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honestly saying I only

Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote: > I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome. This seems to be due to your commit http://reviews.llvm.org/D13841 ,

Hi! Quick question - do you know if recent commits could cause this error, or I should go to bisect/debug this? Do we have tests that check that -gsplit-dwarf succeeds (i.e. compile and link step work)? $ cat a.cc int foo(int x) { return x + 1; } int main() { return foo(42); } $ ./bin/clang++ -gsplit-dwarf a.cc /tmp/a-005b1a.o(.debug_pubnames+0x6): error: undefined reference to

Hi, For lllvm 3.7 and before BUILD_SHARED_LIBS=ON would produce versioned shared libs like libLLVMLTO.so (symlink) libLLVMLTO.so.3.7 (symlink) libLLVMLTO.so.3.7.0 (real file) now it just builds an unversioned libLLVMLTO.so file which I believe is a problem because when a program links to llvm it generates a runtime dependency on libLLVMLTO.so instead of libLLVMLTO.so.3.7.0 which will break

Hi, On Tue, Jan 19, 2016 at 7:18 PM, Chris Bieneman <beanz at apple.com> wrote: > The LLVM libraries are not API stable (especially not the ones you generate with BUILD_SHARED_LIBS). Those libraries are really not intended to ship. I know that's why I need them versioned. Currently we (openSUSE) ship libLLVM package which will install libLLVMFooBar.so.3.7 files and llvm-devel

Hi I found basically all llvm libraries are statically linked into each executable and LLVMgold.so, This make the clang/llvm package larger and larger with a lot of duplicated code. If I build debug version, the disk space required is even larger. Is there any particular reason to keep doing this way? If we separate several shared libraries something like libclang.so, libllvm.so and let

Hi, On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: > Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match functionality between CMake and the autoconf build. > > In the autoconf build we didn't actually set the SOVERSION on

Hi all ! We have an issue with LLD, it is "relocation R_X86_64_32 out of range" (PR31109) which occurs during resolving relocations in debug sections. It looks happens because .debug_info section can be too large sometimes and 32x relocation is not enough to represent the value. One of possible solutions looks to be to deduplicate information to reduce .debug_info size. The rest of

The test in question is clang-check-mac-libcxx-fixed-compilation-db.cpp which copies clang-check to a local directory to make sure clang can find libcxx via rpath. However, when built with shared libs, the copy of clang-check can't find any of it's libraries, so I'd like to either turn if off when BUILD_SHARED_LIBS=ON, or find a way to fix it. Thought about trying to use

Folks, we work on optimization of binary size and improvement of debug info quality. To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage

Dear all, while trying to build llvm with shared libraries using GCC (tested both in Ubuntu 14.04 and Ubuntu 16.04) as in cmake -G Ninja -DBUILD_SHARED_LIBS=ON I run into the following link error lib/Transforms/IPO/CMakeFiles/LLVMipo.dir/PartialInlining.cpp.o: In function `llvm::ForwardDominanceFrontierBase<llvm::BasicBlock>::ForwardDominanceFrontierBase()':

On Wed, Jan 27, 2016 at 3:18 AM, Ismail Donmez via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: >> Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match

Hi, I am seeing an LLVM build failure with recent LLD on x86 like: [...] lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAgg ressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfil eData.a

> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Jan 14, 2016, at 9:38 AM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: >>> >>> On 14 January 2016 at 11:24, David Jones via llvm-dev

The summary stats for the xin and yin variables below are correct. However, if I use plot(xin,yin), an exception is thrown saying that "object xin is not found." Also, it is apparent that I can't successfully replace the x and y vectors with values from xin and yin. The four plots on one panel are showing but the range of x and y is only [0,1], and therefore, it seems like an

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu] Sent: Wednesday,