Subject: Re: Kernel compile problem (vax)
To: Johnny Billquist <bqt@softjar.se>
From: None <lucc@alge.anart.no>
List: port-vax
Date: 07/08/2007 19:06:25
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
>