[LLVMdev] Multiple Definition error with LTO

[Rafael Espíndola]

I cannot reproduce it on x86_64-pc-linux. What I would suggest:

Run clang with -v to get the linker invocation. Copy and past that but
add -t, the linker should print the member it is fetching. It should
show you if it is fetching a member defining memcpy from libc.a.


On 4 June 2014 14:58, Daniel Stewart <stewartd at codeaurora.org> wrote:
> I’m trying to understand why using a local memcpy with LTO results in a
> “multiple definition” error.
>
>
>
> I have an local (optimized) mempy.c (clearly simplified!):
>
>
>
> void* memcpy(void* dest, const void* src, unsigned int count) {
>
>   return 0;
>
> }
>
>
>
> void* __aeabi_memcpy(void *dest, const void *src, unsigned int size) {
>
>   return memcpy(dest,src,size);
>
> }
>
> ---
>
> I also have a simple main.c  to test it out (also simplified):
>
> #include <stdio.h>
>
> #include <string.h>
>
>
>
> struct {
>
>   char name[40];
>
> } person;
>
>
>
> char myname[] = "abcd";
>
>
>
> int main ()
>
> {
>
>   memcpy ( person.name, myname, strlen(myname)+1 );
>
>
>
>   printf ("name :%s\n", person.name );
>
>   return 0;
>
> }
>
> ---
>
>
>
> During compilation with:
>
> clang -O0 memcpy.c -o memcpy.o  -c
>
> ar cr memcpy.a memcpy.o
>
> clang –O0 -o memcpyTest.exe  -flto -static main.c  memcpy.a
>
>
>
> I get a multiple definition of memcpy error. Now building it with
> –fno-builtin works fine. I’m trying to understand what is happening behind
> the scenes that requires my use of –fno-builtin (or
> –Wl,--allow-multiple-definitions). Did the backend put in references to libc
> that are trying to get resolved before loading the optimized archive? I also
> notice that replacing memcpy.a with memcpy.o works just fine as well. Can
> someone give me some insight?
>
>
>
> I’ve found this discussion regarding GCC that seems to center around the
> same issue.
>
>
>
> Daniel
>
>
>
> --
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
> The Linux Foundation
>
>