similar to: [LLVMdev] RFC: Using zlib to decompress debug info sections.

On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com>wrote: > >> Hi! >> >> TL;DR WDYT of adding zlib decompression capabilities to LLVMObject >> library? >> > >> ld.gold from GNU binutils has --compress-debug-sections=zlib option,

On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com>wrote: > Hi! > > TL;DR WDYT of adding zlib decompression capabilities to LLVMObject library? > > ld.gold from GNU binutils has --compress-debug-sections=zlib option, > which uses zlib to compress .debug_xxx sections and renames them to > .zdebug_xxx. > binutils (and GDB) support this properly,

On Tue, Apr 16, 2013 at 9:37 AM, Alexey Samsonov <samsonov at google.com> wrote: > > On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at gmail.com> > wrote: >> >> On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com> >> wrote: >>> >>> Hi! >>> >>> TL;DR WDYT of adding zlib decompression

Just in case - do we want to link with libz.so installed in the system, or be self-contained and copy sources to LLVM repo? On Tue, Apr 16, 2013 at 10:48 PM, Eric Christopher <echristo at gmail.com>wrote: > On Tue, Apr 16, 2013 at 9:37 AM, Alexey Samsonov <samsonov at google.com> > wrote: > > > > On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at

Historically we've done the former. The latter would require Chris wanting to do that. -eric On Tue, Apr 16, 2013 at 11:52 AM, Alexey Samsonov <samsonov at google.com> wrote: > Just in case - do we want to link with libz.so installed in the system, or > be self-contained and copy sources to LLVM repo? > > > On Tue, Apr 16, 2013 at 10:48 PM, Eric Christopher <echristo

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

COFF lld doesn't support the linker script at the moment, and I'm sad to say that it is very unlikely to support that in the future. Linker script support is so huge that I can't imagine we really want it for COFF. GNU BFD linker supports it because the linker is built as an interpreter for the built-in linker script (and that's one of the reasons why GNU linker is by far more

Hello, I have a user who is trying to get LLD to link for the cygwin target: https://github.com/zig-lang/zig/issues/751 Currently the issue they are running into is needing to define a linker script, but the COFF driver (or MinGW driver) does not have support for that. Is there documentation or advice for how to use LLD to link for cygwin? As a starting point, which driver to use? Regards,

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that

On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is

This might be a bit late, but I've got another argument for bundling zlib source with LLVM. Sanitizer tools need to symbolize stack traces in the reports. We've been using standalone symbolizer binary until now; sanitizer runtime spawns a new process as soon as an error is found, and communicates with it over a pipe. This is very cumbersome to deploy, because we need to keep another

On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>

Hi, Using master at b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8, I cannot build LLVM. I configured with: CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=OFF \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \

Hi @ll, Over the past years I have been looking into how to reduce the size of the SDK that ships with Xcode and how to improve build times for the overall OS inside Apple. The result is a tool called TAPI, which is used at Apple for all things related to text-based dynamic library files (.tbd). What are text-based dynamic library files? Text-based dynamic library files (TBDs) are a textual

You shouldn't need to use bitcode and opt -internalize to hide the symbols. You can do it with objcopy --localize-hidden like we did for DynamoRIO, but I assume you prefer this route because it ports nicely to Mac. :) On Tue, May 7, 2013 at 5:24 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > This might be a bit late, but I've got another argument for bundling >

On Wed, Apr 17, 2013 at 12:37 AM, Chris Lattner <clattner at apple.com> wrote: > On Apr 16, 2013, at 11:53 AM, Eric Christopher <echristo at gmail.com> wrote: > > Historically we've done the former. The latter would require Chris > > wanting to do that. > > This case isn't so clearcut. We like to include libraries in the source > to make it easy to get

I was looking to write a cross platform utility that worked with ELF/DWARF files. I need the utility to run on OS X, Linux and Windows. I figured I could use clang/llvm to build this tool. I've made good progress on OS X. Before I got too far, though. I decided to verify that I can build the code on Windows. I downloaded the 3.8.0 Windows installer from the llvm downwloads page, ran the

On Apr 16, 2013, at 11:53 AM, Eric Christopher <echristo at gmail.com> wrote: > Historically we've done the former. The latter would require Chris > wanting to do that. This case isn't so clearcut. We like to include libraries in the source to make it easy to get up and running without having to install a ton of dependencies. However, this has license implications and is

On 06/18/2015 06:46 PM, Dan Liew wrote: >> The issue is the that that generated LLVMExports.cmake file has this in it >> INTERFACE_LINK_LIBRARIES "LLVMObject;LLVMSupport;C:\Program Files (x86)\Microsoft Visual Studio 14.0\DIA SDK\lib\diaguids.lib" > > Hmm actually this might be a bug in the > ``/lib/DebugInfo/PDB/CMakeLists.txt`` file. CC'ing Zach Turner seeing