Solaris DDI/DKI revisited

Solaris DDI/DKI revisited

[Frank Middleton]

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

Re: Solaris DDI/DKI revisited

[Frank Middleton]

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

Any insights would be much appreciated.

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

Re: Solaris DDI/DKI revisited

[LLeweLLyn Reese]

Frank Middleton <f.a.middleton@verizon.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
> >