This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Solaris DDI/DKI revisited
- From: LLeweLLyn Reese <llewelly at lifesupport dot shutdown dot com>
- To: Frank Middleton <f dot a dot middleton at verizon dot net>
- Cc: fam at apogeect dot com, gcc-help at gcc dot gnu dot org
- Date: 14 Mar 2003 16:00:51 -0800
- Subject: Re: Solaris DDI/DKI revisited
- References: <3E4D7841.6080400@verizon.net> <3E722282.30008@verizon.net>
Frank Middleton <f dot a dot middleton at verizon dot net> writes:
> There are four obvious reasons why this didn't get any replies
>
> 1) Sent to the wrong list
> 2) On review there doesn't seem to be a question
> 3) There is no known solution
I think (3) in the sense that no one here kknows.
> 4) The replies were lost
>
> If the reason is 2) then here is a question (observing that there
> was no solution posted on sunsolve either):
>
> What to do about the undefined symbol 'memcpy'?
I think gcc expects the freestanding environment to provide
memcpy. See:
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Standards.html#Standards
and search for the first paragraph containing memcpy.
> Any insights would be much appreciated.
Try implementing your own memcpy, say, as a wrapper around bcopy.
>
> Frank Middleton wrote:
> > Using GCC 3.2.2 with the -m64 option to build a device driver
> > results in an undefined symbol 'memcpy' at attach time.
> > This is because the Solaris 8 kernel doesn't support memcpy;
> > you have to use bcopy instead. However none of the programs
> > in the driver use memcpy as far as I can tell, so there must
> > be something in a library that's referencing it.
> > This question was asked back in May of 2002 (gcc 2.95.2) but
> > apparently unresolved. It was also asked on the drivers forum
> > at sunsolve. It doesn't seem to be a problem if you use Sun's
> > compiler.
> > Thanks
> > Frank Middleton
> >