Subject: Re: something wrong with ELF, lint, libkvm, xemacs...
To: Yasuhiro Ohara <yasu@sfc.wide.ad.jp>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: port-alpha
Date: 12/10/1999 11:02:11
On Thu, 9 Dec 1999, Yasuhiro Ohara wrote:
> Hi, I'm a new netbsd/alpha user.
> Sorry for this long, hard to read mail.
> Please help me if you have time.
> If these question is FAQ, wrong ML, I'm sorry.
>
> I have installed with 1.4.1 floppy and
> have compiled all from cvs updated current source.
> Current source seemed not so easy to compile for me.
> I changed source a little. I want to know that
> is it due to my mis-setting of environment
> (e.g. /usr/include) or not.
As Frank said, a lot has changed. I'd suggest getting a snapshot.
If you're going to build from source, I'd suggest building the entire tree
into a DESTDIR so that you don't have to overwrite running executables.
> 1, Interface to execute ELF
>
> I added some #define like..
>
> ---------------------
> /* elf64 */
> #elif defined(ELFSIZE) && (ELFSIZE == 64)
> #define ELFMAG Elf64_e_ident
> #define SELFMAG Elf64_e_siz
> #define ELFCLASS 2
> #define ELF64_ST_BIND(x) ELF_SYM_BIND(x)
> #define ELF64_ST_TYPE(x) ELF_SYM_TYPE(x)
> #define Elf_Sword Elf64_Shalf
> #endif
>
> #define ELF_ST_INFO(x,y) (((Elf_Byte)ELF_SYM_BIND(x)) | (Elf_Byte)ELF_SYM_TYPE(y))
> #define ELF_ST_BIND(x) (ELF_SYM_BIND(x))
> #define ELF_ST_TYPE(x) (ELF_SYM_TYPE(x))
> ---------------------
>
> I know little what this means.
> What is the right way to compile clean?
You should have not needed that. Sounds like you were using 1.4.1 includes
to try and build a -current system. Either read up on how to build with
DESTDIR & make build, or grab the snapshot. :-)
> 2, lint(1) warns "may lose accuracy" while make
>
> for example, compiling basesrc/lib/libkvm,
> lint warns like this...
>
> ---------------------
> lint -chapbxzF -DLIBC_SCCS -i kvm.c
> kvm.c(344): warning: conversion to 'unsigned long' due to prototype, arg #3
> kvm.c(415): warning: conversion to 'unsigned long' due to prototype, arg #2
> kvm.c(418): warning: conversion to 'unsigned long' due to prototype, arg #4
> kvm.c(497): warning: conversion to 'unsigned long' due to prototype, arg #4
> kvm.c(497): warning: conversion to 'long' due to prototype, arg #5
> kvm.c(526): warning: conversion from 'unsigned long' may lose accuracy
> kvm.c(581): warning: conversion to 'unsigned long' due to prototype, arg #3
> kvm.c(586): warning: conversion from 'unsigned long' may lose accuracy
> kvm.c(594): warning: conversion from 'unsigned long' may lose accuracy
> kvm.c(595): warning: conversion to 'unsigned long' due to prototype, arg #3
> kvm.c(600): warning: conversion from 'unsigned long' may lose accuracy
> kvm.c(604): warning: conversion to 'unsigned long' due to prototype, arg #3
> kvm.c(609): warning: conversion from 'unsigned long' may lose accuracy
> ---------------------
>
> Is this serious? If not, I never mind.
>
> 3, ps didn't work
>
> I found kvm_getprocs() failed in ps...
> when I commented out kvm_proc.c:line 441...
> (changed not to return if returned size seems strange)
>
> ---------------------
> if (size % sizeof(struct kinfo_proc) != 0) {
> _kvm_err(kd, kd->program,
> "proc size mismatch (%d total, %d chunks)",
> size, sizeof(struct kinfo_proc));
> /* return (0); */
> }
> nprocs = size / sizeof(struct kinfo_proc);
DON'T do this. The problems you're seeing are because the libkvm you're
using is out of sync with your kernel. If you have the two in sync, you
won't get this error.
> Is there anybody who experienced this?
> I didn't follow kernel codes.
Try a snapshot. You'll probably be much happier. :-)
Take care,
Bill