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