Re: Compile problems libgtop

[Rebecca Ore <rebecca ore op net>]

On Mon, Jan 04, 1999 at 01:42:28AM +0100, Martin Baulig wrote:
> Rebecca Ore <rebecca.ore@op.net> writes:
> 
> Well, if you're using the libgtop tarball from ftp.gnome.org line 180 in
> netload.c is not the same than in the CVS tree - just looked at this tarball
> and now I know what's causing this bug !
> 
> It stops at the
> 
> #if GLIBTOP_LINUX_VERSION_CODE < 131442
> 
> line - so I guess GLIBTOP_LINUX_VERSION_CODE isn't determined correctly
> in configure.in.
> 
> Normally config.h should have something like this in it:
> 
> /* Same as LINUX_VERSION_CODE either from <linux/version.h> or from
>  * the running kernel (if we don't have configured kernel sources).
>  */
> #define GLIBTOP_LINUX_VERSION_CODE 131584
> 
> This is either taken from <linux/version.h> if that exists (only if you
> run at least a 'make config' in /usr/src/linux) or from the running kernel.
> 
> When running autogen.sh, does it correctly detect this constant ? - it should
> look like this with kernel 2.2.0-pre4:
> 
> 	checking for working ORBit environment... (cached) yes
> 	checking for gnorba libraries... (cached) yes
> 	checking for libgtop sysdeps directory... linux
> 	checking for linux/version.h... (cached) yes
> 	checking for Linux kernel version code... 131584
> 	checking for machine.h in libgtop sysdeps dir... no
> 	checking whether we need libgtop... no
> 	checking for u_int64_t... (cached) yes
> 
> This number should be 131107 for Kernel 2.0.35.

Well, here is something missing, isn't it?  You want to have configure
bail if this fails to show up?  What's been so frustrating is having the
thing try so long.  Early bailout for critical missing bits are your
friend as well as mine as
"She-Who-Only-Beta-Tests-and-Does-Not-Write-Patches."  


cking what language compliance flags to pass to the C compiler... 
checking for gnome-config... /usr/local/bin/gnome-config
checking if /usr/local/bin/gnome-config works... yes
checking for orbit-config... /usr/local/bin/orbit-config
checking for orbit-idl... /usr/local/bin/orbit-idl
checking for working ORBit environment... yes
checking for gnorba libraries... yes
checking whether to enable SMP support... no
checking for libgtop sysdeps directory... linux
checking for linux/version.h... no
./configure: dc: command not found
checking for Linux kernel version code... 
checking for machine.h in libgtop sysdeps dir... no
checking whether we need libgtop... no
checking for u_int64_t... yes
checking for int64_t... yes

Well, there it isn't, isn't it.  If the sucker had died in config...

So, will this require a built kernel?  Or what?




> 
> I'll look at this a little bit closer tomorrow.
> 
I've rebuilt guile.  I get this for acloud:

[rebecca@ogoense rebecca]$ aclocal --print-ac-dir
/usr/share/aclocal

...and I also have a bunch of things in /usr/local/share/aclocal/, but
this seems like a less major problem than not knowing what the kernel
code is.

Is configure written to a file?  The XEmacs guys have Installation which
captures it -- putting in code to do this might make debugging easier
unless it's config.cache and/or I haven't look hard enough.

-- 
Rebecca Ore
Creativity is playing with the rule sets