Re: Compile problems libgtop



Rebecca Ore <rebecca.ore@op.net> writes:

> 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

Ah, `dc' was not found and so it fails to set GLIBTOP_LINUX_VERSION_CODE
from the running system.

> 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?

No. Just tested this with RedHat 5.2 - it does not need a built kernel,
it only requires

	kernel-2.0.36-0.7
	kernel-headers-2.0.36-0.7

Normally <linux/version.h> is created during kernel configuration, but it
is included in the `kernel-headers-2.0.36-0.7' RPM from RedHat 5.2 - I don't
know it this is also the case for kernel 2.0.35.

However, this should work for 2.0.35:

#define UTS_RELEASE "2.0.35"
#define LINUX_VERSION_CODE 131107

Martin

Btw.: `dc' is in the bc-1.05a-1 RPM (RedHat 5.2)

-- 
-----------------------------------------------------------------
   Martin Baulig - Angewandte Mathematik - Universitaet Trier
   martin@home-of-linux.org, http://www.home-of-linux.org/
------------------------------------------------------------------



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]