T.R | Title | User | Personal Name | Date | Lines |
---|
8823.1 | | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Thu Feb 13 1997 17:30 | 7 |
|
Check to see if the <netinet/in_var.h> matches the timeframe
of your /usr/sys/BINARY/in.o file. Those symbols are from (defined in)
newer (patched) versions of in.o (post April 1996).
Sorry, I do not know the patch ID for the associated fix.
|
8823.3 | | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Fri Feb 14 1997 14:32 | 13 |
|
Since I do not know what files are looking for the definition
and these symbols do not exist on my V3.2C system (no patches)
we need to find out who might be requesting them in some other
module
Try
# cd /usr
# find . -name '*.o' | xargs nm | (grep -E '\:|inifaddr_hmask') > a.a
and looking in the resulting file for the symbol name and object
file name.
|
8823.4 | new data | EDSCLU::KELLY | | Fri Feb 14 1997 14:44 | 16 |
| I checked the dates for the "in.o" and "in_var.h" and the dates were JUlY
24 and JULY 25.
Suspecting that one of the layered products could have been built on an
3.2g machine, we copied the "in.o" and "in_var.h" files from the 3.2g
machine to the 3.2c machine. We then ran the kernel build and it completed
successfully.
Will this work (is the kernel o.k.) or do we need to
upgrade the 3.2c machine to version 3.2g and rebuild
the kernel ??
Thanks,
Jim Kelly
|