[LLVMdev] Multiple Definition error with LTO

[Daniel Stewart]

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

 

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

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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