[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Bizarre compile/link problem from minor change
Perhaps someone who is smarter (or at least has more compiler/linker knowledge than me :-) can solve this bizarre problem: I have been annoyed for some time with a hack that's in xen/common/string.c... For the routine memcpy(), there is an #undef right before it. Why not do this properly and use the #ifndef __HAVE_ARCH_MEMCPY around it, like all the other routines? So I tried it. And got an undefined reference reported by the linker from arch/x86/vmx.o. Looking at arch/x86/vmx.c, there's no reference to memcpy. And if you look at the output from cpp, there's no reference to memcpy. If you add a #include for <xen/string.h> after <xen/lib.h>, it doesn't fix anything. To try to force the compiler to tell me where the problem lay, AHA, I added a line at the beginning of the source: void memcpy(void) {} thinking that the compiler would surely report a mismatch. It didn't and the compile/link succeeds! Clearly adding this line is not a nice solution. Can anyone come up with a better one? (Other than just leaving string.c as is...) Please try your solution yourself... I tried a few and couldn't find one that worked. If you find one, kindly reply to this post. Maybe I'm just tired.... Dan ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |