CLang/LLVM SVN for today no longer works on OS X 10.7.4

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 version it is

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 "cctools".

This is the ranlib version:

@(#)PROGRAM:cctools_misc PROJECT:cctools-809 DEVELOPER:root
BUILT:Thu Nov 3 14:06:33 PDT 2011

I will have to try another build tomorrow to give you information on
the object files.

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
  fileoff 464
filesize 2304
  maxprot rwx
initprot rwx
   nsects 3
    flags (none)
Section
  sectname __text
   segname __TEXT
      addr 0x0000000000000000
      size 0x00000000000006b6
    offset 464
     align 2^4 (16)
    reloff 2768
    nreloc 9
      type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
reserved1 0
reserved2 0
Section
  sectname __compact_unwind
   segname __LD
      addr 0x00000000000006b6
      size 0x00000000000000e0
    offset 2182
     align 2^0 (1)
    reloff 2840
    nreloc 7
      type S_REGULAR
attributes DEBUG
reserved1 0
reserved2 0
Section
  sectname __eh_frame
   segname __TEXT
      addr 0x0000000000000798
      size 0x0000000000000168
    offset 2408
     align 2^3 (8)
    reloff 0
    nreloc 0
      type S_COALESCED
attributes NO_TOC STRIP_STATIC_SYMS LIVE_SUPPORT
reserved1 0
reserved2 0
Load command 1
      cmd ?(0x00000029) Unknown load command
  cmdsize 16
00000b50 00000008
Load command 2
     cmd LC_SYMTAB
cmdsize 24
  symoff 2904
   nsyms 17
  stroff 3176
strsize 312
Load command 3
            cmd LC_DYSYMTAB
        cmdsize 80
      ilocalsym 0
      nlocalsym 15
     iextdefsym 15
     nextdefsym 2
      iundefsym 17
      nundefsym 0
         tocoff 0
           ntoc 0
      modtaboff 0
        nmodtab 0
   extrefsymoff 0
    nextrefsyms 0
indirectsymoff 0
  nindirectsyms 0
      extreloff 0
        nextrel 0
      locreloff 0
        nlocrel 0

Seriously though, it seems to be pretty clear from my limited research
that some time, recently, LLVM started writing a load command 1 into
some -- apparently not all -- of the Mach-O files it writes.

This is unrecognized by the Apple OS X tools as of XCode 4.4.1 --
otool doesn't know what that is, ranlib is confused by it.

Maybe it is just ignored by ld when linking an executable, because
things like autoconf configure scripts seem to run OK.

I am not a LLVM hacker. I'm an informed end user of LLVM/CLang, and
I'm willing to try out the trunk compiler, but I'm not qualified to
debug it.

I've logged it as an LLVM bug: http://llvm.org/bugs/show_bug.cgi?id=13973