WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Bizarre compile/link problem from minor change

To: <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Bizarre compile/link problem from minor change
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Mon, 10 Jan 2005 16:35:36 -0800
Delivery-date: Tue, 11 Jan 2005 02:40:22 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcT3dXegWrv0SIMRTgeH0GY9iusONg==
Thread-topic: 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

<Prev in Thread] Current Thread [Next in Thread>