similar to: [LLVMdev] OSX 10.6 (Snow Leopard): strip: malformed object: clang malformed object (unknown load command 9)

I have a need to build ld from source to understand an assert(0). I got excited when I found that ld64 on the opensource portal contains an xcodeproj http://opensource.apple.com/source/ld64/ld64-127.2/ But... it seems like I'm lacking mach-o/arm/reloc.h, and dyld_priv.h. I'm doing my best to stitch it all together, but if anyone has any pointers to make this less painful, it would be

Thanks for your response, that's kinda what I've gathered over the years. I was hoping that the Xcode project would have "just worked". I'll keep piece-mealing it together, and hope that it works. I'll try to post a radar. Joe Joe Abbey Director of S/W Development Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 W: 765-889-4756 x2 C:

On 14.01.2012, at 17:23, Joe Abbey wrote: > I have a need to build ld from source to understand an assert(0). > > I got excited when I found that ld64 on the opensource portal contains an xcodeproj > > http://opensource.apple.com/source/ld64/ld64-127.2/ > > But... it seems like I'm lacking mach-o/arm/reloc.h, and dyld_priv.h. > > I'm doing my best to stitch

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

Hi Kent, My guess is you are getting some new bit of info in your object files and your ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string

Hi David, > ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember, file /SourceCache/ld64/ld64-136/src/ld/parsers/archive_file.cpp, line 354. This looks like a bug in the Apple linker, which isn't part of LLVM. The best on-topic place to ask would probably be Apple's developer forum (https://devforums.apple.com), but linkers are rather specialised beasts. The

Hi, I'm encountering the following assertion when linking an Xcode project with Xcode 4.6.3 (4H1503). The project has dependencies on, and links against, an Objective-C static library Xcode project, and a C++ static library Xcode project. All are using using LLVM 4.2. ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember, file

Here you go: http://www.cornwarning.com/xfer/jccolor.o (from the jpeg library...) jccolor.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 432 SUBSECTIONS_VIA_SYMBOLS Load command 0 cmd LC_SEGMENT_64 cmdsize 312 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000900

Several folks have been asking about how LLVM is used in Snow Leopard. Now that it has shipped, I updated the Users page here: http://llvm.org/Users.html#Apple One of the major new features of Xcode 3.2 is the integrated static analyzer. Ted will update http://clang-analyzer.llvm.org/ with more details when he has time. -Chris

Are there any patches (or planned updates) to rsync v3.0.6 to handle the HFS+ File Compression that Apple introduced with Snow Leopard?

I believe it's a feature missing in MC - https://github.com/opensource-apple/cctools/blob/4da58fd2fc026317ed9e9ef1feabf21ed0bb7a81/cctools-836/as/i386.c line 539 adds support for the .bss directive if certain variables are defined, and mainline gas supports it on all ARM targets: https://sourceware.org/binutils/docs/as/ARM-Directives.html . Supporting the directive on all Darwin targets could

Hey everyone! Recently there has been some progress on LLVM-based tools for manipulating MachO binaries: llvm-objcopy has been gaining a lot of important bits to support MachO (it's relatively close to the point where one can implement the strip-like functionality), llvm-lipo is functional and supports most of cctools' lipo options (https://llvm.org/docs/CommandGuide/llvm-lipo.html). There

*bitcode_strip* is a utility which is used to manipulate (leave / remove) bitcode segments in a Mach-O file. It is a part of Apple’s cctools and it is also distributed with Xcode. The man page of the tool is available here https://www.manpagez.com/man/1/bitcode_strip/. The functionality of *bitcode_strip* naturally maps onto llvm-objcopy’s model and requires only minimal additions to it.

Hey Michael, I completely agree that setting the rpath properly the first time around is much preferred. But, changes to the binary, particularly during development is much quicker. Prebuilt libraries which are being repackaged is one use case that is missed. In the past, I’ve even used it to repair am incorrectly built library which was missing the library name. There are a few different

Hi - I've attached a patch to make the assembly parser recognise the .bss directive on Darwin targets as a switch to the (__DATA,__bss) section. The ELF & COFF assembly parsers already recongnise the .bss directive. I've added a test case for it too. Thanks - Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: bss.patch Type:

LGTM On 29 September 2013 06:08, Nicholas White <n.j.white at gmail.com> wrote: > I believe it's a feature missing in MC - > https://github.com/opensource-apple/cctools/blob/4da58fd2fc026317ed9e9ef1feabf21ed0bb7a81/cctools-836/as/i386.c > line 539 adds support for the .bss directive if certain variables are > defined, and mainline gas supports it on all ARM targets: >

Is this an extension to what cctools' assembler provides or a missing feature in MC? On 28 September 2013 18:48, Nicholas White <n.j.white at gmail.com> wrote: > Hi - I've attached a patch to make the assembly parser recognise the > .bss directive on Darwin targets as a switch to the (__DATA,__bss) > section. The ELF & COFF assembly parsers already recongnise the .bss

Hello all, I tried to build R-2.3.1 from source under Mac OS X 10.4.6. (I am doing so because only this way I can get the 64-bit version of R) The configure and make steps look fine. But I got errors when I did make check-all, here is the message: running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1 make[3]: *** [test-Examples-Base] Error 2 make[2]: *** [test-Examples]

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O