Well, the behaviour of memcpy and the rest of them is defined well 
enough that it shouldn't be a problem even when they are used in the 
kernel. It's no more dangerous than other kinds of optimizations on the 
code. So the fact that gcc treats them specially shouldn't be a issue.
But I think there is some switch or so to gcc, to make it not use 
built-in versions of different functions. -fno-builtins or something 
like it. Read the man-page... :-)
gcc itself shouldn't break a kernel build. But using different versions 
of a compiler (or different compilers) for different objects for the 
same kernel build is always a danger. Doing a clean before every build 
avoids these problems, but it will take longer, so keeping object files 
around isn't that unusual... And as long as the toolchain don't change, 
it's not a problem.

But like I said from the beginning, this is just guessing on my part. 
Test if a make clean, followed by a build will fix it. If not, then you 
have some other problem that I don't know about.

	Johnny

lucc@alge.anart.no skrev:
> Hi Johnny.
> Thank you very much for this information, I had no idea. It does
> seem rather strange though, that the compiler should be the one to
> actually break a kernel build. The first compile I did was with
> the gcc that comes with the standard installation, all was fine
> untill the linking was being done. Thats where the error occured.
> My first thought was that I had enabled a feature in the kernel
> that required another that was disabled, and in that way I broke
> the dependencies. I kept pf in the kernel (my VAX will be used as
> a router), and also ccd (love that feature!), but removed some
> other, for me, useless abilities. I'll go through the entire
> prossess again later, but as I said, a clean compile takes four
> hours so I want to keep the objects a little longer. A question
> though, how do I know if libc or gcc mem* is being used? Is there
> a way to force the use of one or the other? It seems rather
> inconsistent to use a gcc internal in the kernel, as an upgrade
> of gcc easily could break a perfectly good kernel. Or, again, I
> could be utterly wrong about the whole matter.. ;)
> 
> /Luke
> 
>> Just for you information: memset and so on are normally in libc.
> However, gcc have a few of these functions built in as well, so that
> when they occur in the code, gcc can place some rather optimized code in
> there, instead of doing a call to a function.
>> Thus, it might not consider that memset is required as an external
> function. However, if you build some code where memset isn't internal to
> gcc, an external reference will be created. This is why I suspect you
> might have built different object files with different versions of gcc,
> which have caused it to generate internal code for some parts, and
> external references for others. This could then end up with a library
> for the kernel that don't have memset, since gcc have that one built in,
> but old object files might still require the external version.
>> Another possibility would be that the names of external functions have
> changed in between. I would have thought that it was longer ago, but
> maybe something more recent happened in this area too. In the past,
> external symbols from gcc were always prefixed with "_", but they aren't
> anymore. So you could have a "_memset" defined in you library, compiled
> with an older version of the compiler, and references to "memset" from a
> new version.
>> There could possibly be other explanations as well. The first reaction
> when this happens (for me anyway) is always to do a make clean, and then
> build again, just in case... :-)
>> 	Johnny
>>
>>
>> lucc@alge.anart.no skrev:
>>> Ok, I see. Have always rolled my own kernels, but never met with this
> before. I disabled some features in the kernel, then did a config, make
> depend && make, and it worked just fine. It took 4 hours to compile, so
> i'll have to wait untill I have time again to do it. Thanks for the
> advice. The kernel I managed to build works
>>> fine though, with pf and all :-) (dmesg at the ususal place in alge) /Luke
>>>> I suspect you're doing a build with possibly different version of gcc
> having compiled different object files. Or maybe it's just a question
> of
>>>> a confused toolchain.
>>>> It looks like you're building the kernel by "hand" (without using
> build.sh).
>>>> Maybe rebuild the toolchain first, and then rebuilt the kernel, with a
> make clean in between...?
>>>> 	Johnny
>>>> lucc@alge.anart.no skrev:
>>>>> Kernel compile on VAXstation 4k60:
>>>>> #      link  MAINFRAME/netbsd
>>>>> ld -N -Ttext 80000000 -e start -S -o netbsd ${SYSTEM_OBJ}
> ${EXTRA_OBJ}
>>>>> vers.o
>>>>> sha2.o(.text+0x16): In function `SHA256_Init':
>>>>> : undefined reference to `memcpy'
>>>>> sha2.o(.text+0x26): In function `SHA256_Init':
>>>>> : undefined reference to `memset'
>>>>> sha2.o(.text+0x2ec): In function `SHA256_Update':
>>>>> : undefined reference to `memcpy'
>>>>> <snip all references to SHA{?}>
>>>>> What the... ? Isen't this in the C library (man memset)?
>>>>> AFAIK this should not happen... and never has before on
>>>>> any other NetBSD compile I have done. Either something is
>>>>> wrong with my installation, or I have missed something.
>>>>> /Luke
>>>> --
>>>> Johnny Billquist                  || "I'm on a bus
>>>>                                    ||  on a psychedelic trip
>>>> email: bqt@softjar.se             ||  Reading murder books
>>>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>> --
>> Johnny Billquist                  || "I'm on a bus
>>                                    ||  on a psychedelic trip
>> email: bqt@softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>>
> 
> 
> 
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol