This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: objcopy in binutils doesn't work on Mac OS X


Hi Nick, Eric, Masaki,

On Tue, 2007-02-27 at 17:05 +0000, Nick Clifton wrote:

> This is not just a coincidence.  It is a known problem that the GNU 
> binutils do not currently work properly for darwin based targets.
> 
> > The very same configure statement works well in binutils-2.17.
> 
> Hmm, but I bet that if you left off the "--enable-targets=all" then it 
> would not work ?
> 
> > Can I force it to build binutlils anyway?
> 
> You could edit the top level configure file to allow it, but really the 
> point of the refusal to build is that it is known that the binutils do 
> not (currently) work for darwin.

Here's the story AFAIK:

binutils 2.16.1 from MacPorts patches the configure.in file so that
binutils and bfd build on PPC Darwin.

binutils 2.17 build on my machine without patch since configure only
disables binutils et al on PPC Darwin but fails to check for i386
Darwing (which is what my machine is).

binutils CVS does not build binutils et al when building on PPC or i386
Darwin. I have applied the patch and can build binutils et al. The bugs
are still there. The objdump and objcopy can read .o files but not
archives produces by Apple's ar. GNU ar is unable to create a "mach-o
le" file and confusingly reports an "Invalid operation" and leaves a
dysfunctional archive. To witness:

Using GNU ar:

sinope:~/current/source/tvpi as49$ ~/source/binutils-cvs/binutils/ar
cru libtvpi.a src/memory.o src/interval.o src/planar.o src/polyhedron.o
src/tvpi.o src/affine.o src/tvpi_c.o src/landmark.o
/Users/as49/source/binutils-cvs/binutils/ar: libtvpi.a: Invalid
operation

Using Apple's ar:

sinope:~/current/source/tvpi as49$ rm libtvpi.a 
sinope:~/current/source/tvpi as49$ make libtvpi.a
rm -f libtvpi.a
/usr/bin/ar cru libtvpi.a src/memory.o src/interval.o src/planar.o
src/polyhedron.o src/tvpi.o src/affine.o src/tvpi_c.o src/landmark.o 
ranlib libtvpi.a

Using objdump on .o file:

sinope:~/current/source/tvpi as49$
~/source/binutils-cvs/binutils/objdump -a src/polyhedron.o

src/polyhedron.o:     file format mach-o-le
src/polyhedron.o

Using objdump on .a file produces by Apple's ar:

sinope:~/current/source/tvpi as49$
~/source/binutils-cvs/binutils/objdump -a libtvpi.a 
/Users/as49/source/binutils-cvs/binutils/objdump: libtvpi.a: File format
not recognized

It seems that binutils work ok on PPC Darwin, but not on i386 Darwin.
The CVS version of objdump falls over at the same point as the 2.17
version does, namely when checking the magic number. Changing the magic
number does not work, the file format seems to be totally different. I
naively change the magic number to the value that appears in the library
file at that point. In gdb:

1695      if (adata->magic != 0x213c6172) /* 0xcafebabe) */
(gdb) print adata->magic != 0x213c6172
$2 = 0
(gdb) next
1698      adata->archentries = 
(gdb) next
1700      if (adata->archentries == NULL)
(gdb) next
1703      for (i = 0; i < adata->nfat_arch; i++)
(gdb) print *adata
$4 = {
  magic = 557605234, 
  nfat_arch = 1667776010, 
  archentries = 0x3c08008
}

So this loop iterates of 16 million entries, which is not correct. In
fact, the loop bails out after only 2 iterations when some of the bfd
function fail.

As for Eric's suggestion, I don't think I have the knowledge to fix
these file format issues by looking at, say, the gdb way of reading the
archives of Apple's ar. So I'd appreciate any other help!

Thanks for all your feedback so far,
Axel.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]