search for: ncmds

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

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

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

...gt; > * Fix descriptor directions. For the outgoing frames num_in was > incremented instead of num_out. > > The frames in the for-loop may be outgoing or intended for incoming > data. Decided on the RPMB_F_WRITE flag what to do with those frames: > > for (i = 0; i < ncmds; i++) { > ... > > if (cmds[i].flags & RPMB_F_WRITE) > sgs[num_out++ + num_in] = &frame[i]; > else > sgs[num_out + num_in++] = &frame[i]; > } > > * Got now too much data comparing to the virtio spec. R...

Hi, The specification lists a number of commands that have responses: The operation of a virtio RPMB device is driven by the requests placed on the virtqueue. The type of request can be program key (VIRTIO_RPMB_REQ_PROGRAM_KEY), get write counter (VIRTIO_RPMB_REQ_GET_WRITE_COUNTER), write (VIRTIO_RPMB_REQ_DATA_WRITE), and read (VIRTIO_RPMB_REQ_DATA_READ). A program key or write