undefined reference to `memset'

Vinod Kashyap vkashyap at amcc.com
Fri Mar 25 14:38:17 PST 2005


> > Can you not submit it with the patch I sent?
> 
> Submit the entire /usr/src/sys kernel source??
> 
> > A "stand alone" foo.c will have to be a new module under a new
> > directory (/sys/dev/foo), with its own Makefile, with changes to
> > /sys/conf/files, and an entry in GENERIC.
> 
> A module would still depend on files in /usr/share/mk, 
> /usr/src/sys/conf,
> /usr/src/sys/modules, /usr/src/sys/dev/foo.
> 
> NO! nothing other than a single file -- foo.c in my home 
> directory that
> shows the problem is a "stand alone" example.

Here is memset_issue.c (also attached).  But note that you cannot
reproduce the "undefined reference to `memset'" issue with this
(that's what I have been trying to explain).  You could also use
the earlier posting from Sean McNeil.

#include <stdio.h>

main()
{
	char a[100] = {0};
	char *ap;

	ap = &(a[0]);
	printf("a[0] = %d\n", a[0]);
}


With the patch that I sent earlier applied to /sys/dev/twa/twa.c,
'nm twa.o' shows this when twa is built as a stand alone module:
00000000000003f0 t memset

'nm twa.o' shows this when twa is built as part of the kernel:
                 U memset


And now, moving to the important thing... in kern.pre.mk, I changed
COPTFLAGS from -O2 to -O for amd64 (just like i386), and the problem
is gone!!
-------------- next part --------------
#include <stdio.h>

main()
{
	char a[100] = {0};
	char *ap;

	ap = &(a[0]);
	printf("a[0] = %d\n", a[0]);
}


More information about the freebsd-stable mailing list