[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to fix Makefile.clang in libobjc2
From: |
David Chisnall |
Subject: |
Re: Patch to fix Makefile.clang in libobjc2 |
Date: |
Mon, 8 Aug 2011 17:00:44 +0100 |
On 8 Aug 2011, at 16:15, Charlie Sharpsteen wrote:
> Oops, the first patch I sent out was short a couple of changes that added
> files like arc.m, associate.m and a garbage collection source. Attached is a
> complete patch.
Thanks - applied.
> Also, it looks like the file blocks_runtime.m is compiled by the other
> Makefiles, but Clang doesn't like it for some reason:
>
> Linking bitcode...
> llvm-ld: error: Cannot link file 'blocks_runtime.bc': Linking globals named
> 'block_getType_np': symbol multiply defined!
That's strange - I don't get that message. Note this isn't a clang message -
clang is emitting the bitcode. At this stage, we're using llvm-ld to link them
all together, optimise them, and produce a single .o file, which we then pass
off to the system linker for the final bit of linking.
> I have no idea why there would be multiply defined symbols---everything seems
> to be declared appropriately.
It's possible that another file is accidentally defining it from the
declaration in the header. The way to track this down is to see which of the
.bc files contains the reference. You can use llvm-nm on .bc files in the same
way that you use nm on .o files.
$ llvm-nm obj/blocks_runtime.bc | grep block_getType_np
T block_getType_np
So, this file is defining this function once. If you're seeing the error when
it tries to link this one, it probably means that another .bc file is also
trying to define it. For me, it's only present in two .bc files: libobjc.bc
and blocks_runtime.bc - the former being the linked version of the later.
David
-- Sent from my Difference Engine