undefined reference to `memset'

Vinod Kashyap vkashyap at amcc.com
Thu Mar 24 19:52:48 PST 2005

> -----Original Message-----
> From: Sean McNeil [mailto:sean at mcneil.com]
> Sent: Thursday, March 24, 2005 7:15 PM
> To: Vinod Kashyap
> Cc: Peter Jeremy; freebsd-stable at freebsd.org; 
> freebsd-amd64 at freebsd.org
> Subject: RE: undefined reference to `memset'
> Vinod,
> On Thu, 2005-03-24 at 19:01 -0800, Vinod Kashyap wrote:
> > Just like the problem is not seen when I build only the module, it's
> > not seen if I simply write a foo.c (with the example code) 
> and compile it.
> > That's the reason I posted the patch to /sys/dev/twa/twa.c, 
> which would
> > cause the problem if applied, and then followed with a kernel build.
> > I can send the result of running nm on twa.o tomorrow.
> Please take a look at other messages in this thread, like some of the
> ones I have posted.  They clearly show your problem in a small example
> and how it is happening in the -O2 case as memset is being optimized
> away.  -O would appear to do the right thing and adding
> -minline-all-stringops (at either optimization level) would 
> produce even
> better code.

I did look at your posting Sean, thanks.  But did you see the
"undefined reference to `memset'" linker error when you built it?
It's obvious that a reference to memset is being generated by
the initialization of an array of 100 bytes to 0.  The linker is getting
the needed memset if you build a stand alone program, or even build a stand
alone kernel module, but is not being able to find it when building
the kernel itself.  This implies to me that it is a difference in
the use of flags, or linking/not linking with particular libraries
that's causing the problem.

I am also confused as to how an explicit call to memset works,
when compiler generated call doesn't!  Are we talking 2 different
memset's here?  Maybe a memset and an __memset?

More information about the freebsd-stable mailing list