[LLVMdev] Multiple Definition error with LTO

[Daniel Stewart]

Thanks for the reply Rafael. I've ran it with both -t and -Wl,-debug=all to see what the linker is grabbing. 

Without -fno-builtin, it grabs libc first.

With -fno-builtin, it loads in my archive first. 

What I don't know is how it is making that decision. I will see if I can reproduce on x86_64. 

-----Original Message-----
From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] 
Sent: Wednesday, June 04, 2014 3:31 PM
To: Daniel Stewart
Cc: LLVM Developers Mailing List
Subject: Re: Multiple Definition error with LTO

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
>
>