bug-gnustep
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]