digitalmars.D - LC_SEGMENT command 0 filesize field greater than vmsize field
- Jacob Carlborg (9/9) Nov 12 2010 Now this really starts to annoy me. I don't know if it's a bug in Mac OS...
- Michel Fortin (17/25) Nov 12 2010 I've seen something similar too with some transitory test cases while
- Jacob Carlborg (5/26) Nov 12 2010 Ok, thanks. Actually I got the same error now when I compiled derelict2
- Jacob Carlborg (5/26) Nov 13 2010 I used the dumpobj tool to inspect the LC_SEGMENT and just as the error
- Michel Fortin (13/41) Nov 13 2010 backend/machobj.c line 765-766:
Now this really starts to annoy me. I don't know if it's a bug in Mac OS X or in DMD but I'm getting this error when building some libraries (Tango, for example): /usr/bin/ranlib: object: libtango.a(tango-coreBitArray-release.o) malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) ar: internal ranlib command failed -- /Jacob Carlborg
Nov 12 2010
On 2010-11-12 04:08:56 -0500, Jacob Carlborg <doob me.com> said:Now this really starts to annoy me. I don't know if it's a bug in Mac OS X or in DMD but I'm getting this error when building some libraries (Tango, for example): /usr/bin/ranlib: object: libtango.a(tango-coreBitArray-release.o) malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) ar: internal ranlib command failedI've seen something similar too with some transitory test cases while playing with DMD to generate Objective-C data structures. I'd tend to believe there's a bug in the backend. I didn't know this bug could be trigged by compiling code with regular DMD, it could have been something I trigged playing with the compiler to make it generate extra Objectve-C segments/sections. If you want to inspect the object file, I suggest you extract tango-coreBitArray-release.o from the libtango.a archive and play with otool, objdump, dumpobj, and perhaps obj2asm. The first two are provided with Apple's developer tools so they and tend to better reflect the linker in their understanding of the object file format; the later two come with DMD and better reflect Walter's implementation. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Nov 12 2010
On 2010-11-12 14:41, Michel Fortin wrote:On 2010-11-12 04:08:56 -0500, Jacob Carlborg <doob me.com> said:Ok, thanks. Actually I got the same error now when I compiled derelict2 with ldc. -- /Jacob CarlborgNow this really starts to annoy me. I don't know if it's a bug in Mac OS X or in DMD but I'm getting this error when building some libraries (Tango, for example): /usr/bin/ranlib: object: libtango.a(tango-coreBitArray-release.o) malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) ar: internal ranlib command failedI've seen something similar too with some transitory test cases while playing with DMD to generate Objective-C data structures. I'd tend to believe there's a bug in the backend. I didn't know this bug could be trigged by compiling code with regular DMD, it could have been something I trigged playing with the compiler to make it generate extra Objectve-C segments/sections. If you want to inspect the object file, I suggest you extract tango-coreBitArray-release.o from the libtango.a archive and play with otool, objdump, dumpobj, and perhaps obj2asm. The first two are provided with Apple's developer tools so they and tend to better reflect the linker in their understanding of the object file format; the later two come with DMD and better reflect Walter's implementation.
Nov 12 2010
On 2010-11-12 14:41, Michel Fortin wrote:On 2010-11-12 04:08:56 -0500, Jacob Carlborg <doob me.com> said:I used the dumpobj tool to inspect the LC_SEGMENT and just as the error message says, the filesize field is greater than the vmsize field. -- /Jacob CarlborgNow this really starts to annoy me. I don't know if it's a bug in Mac OS X or in DMD but I'm getting this error when building some libraries (Tango, for example): /usr/bin/ranlib: object: libtango.a(tango-coreBitArray-release.o) malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) ar: internal ranlib command failedI've seen something similar too with some transitory test cases while playing with DMD to generate Objective-C data structures. I'd tend to believe there's a bug in the backend. I didn't know this bug could be trigged by compiling code with regular DMD, it could have been something I trigged playing with the compiler to make it generate extra Objectve-C segments/sections. If you want to inspect the object file, I suggest you extract tango-coreBitArray-release.o from the libtango.a archive and play with otool, objdump, dumpobj, and perhaps obj2asm. The first two are provided with Apple's developer tools so they and tend to better reflect the linker in their understanding of the object file format; the later two come with DMD and better reflect Walter's implementation.
Nov 13 2010
On 2010-11-13 07:16:27 -0500, Jacob Carlborg <doob me.com> said:On 2010-11-12 14:41, Michel Fortin wrote:backend/machobj.c line 765-766: segment_cmd.vmsize = vmaddr; segment_cmd.filesize = foffset - segment_cmd.fileoff; I'd put an assert just after those two lines to make sure vmsize is greater or equal to filesize. Running dmd in the debugger should make it break on the failed assertion and perhaps you'll be able to investigate. It seems likely that the problem comes from the loop just above. -- Michel Fortin michel.fortin michelf.com http://michelf.com/On 2010-11-12 04:08:56 -0500, Jacob Carlborg <doob me.com> said:I used the dumpobj tool to inspect the LC_SEGMENT and just as the error message says, the filesize field is greater than the vmsize field.Now this really starts to annoy me. I don't know if it's a bug in Mac OS X or in DMD but I'm getting this error when building some libraries (Tango, for example): /usr/bin/ranlib: object: libtango.a(tango-coreBitArray-release.o) malformed object (LC_SEGMENT command 0 filesize field greater than vmsize field) ar: internal ranlib command failedI've seen something similar too with some transitory test cases while playing with DMD to generate Objective-C data structures. I'd tend to believe there's a bug in the backend. I didn't know this bug could be trigged by compiling code with regular DMD, it could have been something I trigged playing with the compiler to make it generate extra Objectve-C segments/sections. If you want to inspect the object file, I suggest you extract tango-coreBitArray-release.o from the libtango.a archive and play with otool, objdump, dumpobj, and perhaps obj2asm. The first two are provided with Apple's developer tools so they and tend to better reflect the linker in their understanding of the object file format; the later two come with DMD and better reflect Walter's implementation.
Nov 13 2010