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
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140604/0756c863/attachment.html>
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 > >
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 > >