This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Solaris DDI/DKI revisited


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
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]