Hrm. We should really remove martin from the maintainership assign
here. Kevin, any idea if anyone works on this ATM?

Luis: I don't have access to any Sun machines so I'm no help here (nor
do I know anything really about libgtop ;)

I can confirm similar compile problems on my Solaris 8 machine.  I had
limited success in getting it to compile by playing with the
VERSION_CODE, but then wasn't able to get anything that uses ligbtop
to compile successfully.

If anyone can point me in the right direction, I'd be glad to help.  

I have the same problems, both on sparc and x86 Solaris.  I also have
problems with building the libgtop_server (or something like that,
can't recall right now..). After a little examination of the created
Makefiles I fixed it. 

Also had to add "typedef unsigned long long u_int64_t;" in the
beginning of libgtop.h after installation, otherwise other stuff
wouldn't compile.  I "fixed" the buildproblems by changing the version
string that is tested in the c-files to something like "2001002"....

And yes, the whole package doesn't work as well as it should (at least
not on a Solaris-box), so perhaps the guys at wipro/Sun could take a
look at it??

I have the same problems in compliling libgtop on solaris 8. I traced
it to:
 
In file <basedir>/sysdeps/solaris/cpu.c cpu.c line 54,  function
glibtop_get_cpu_s calls a structure glibtop_cpu and on line 84, does
this:
	buf->xcpu_flags |= (1L << cpu);

However, in file <basedir>/include/glibtop/cpu.h, where the structure
glibtop_cpu is defined, xcpu_flags is NOT a member of the structure. 

I assume that it is due to this that we see an error.

Also, in file cpu.c, a file <basedir>/sys/processor.h is included by
saying :  #include <sys/processor.h>
but I found no file in this name in the distribution ( I got the
distribution from ftp.gnome.org)

In file cpu.c, the above instruction is executed only if the version
code is  >= 1001002. So, we can compile this by making the version
code less than 1001002. But, i dont know what implications it will
have on codes complied using glibtop libraries.

I have not done much C programming, so do correct me if I am wrong.


Krishnan

*** Bug 76817 has been marked as a duplicate of this bug. ***

76817 brings up the u_int64_t issue - I'm assuming if this bug is
resolved, that issue will be fixed.

*** Bug 76792 has been marked as a duplicate of this bug. ***

bug 76792 also mentions issues compiling which are brought up here

*** Bug 76792 has been marked as a duplicate of this bug. ***

This bug is seriously stagnating.  Does anyone know if there are Sun
people that could be pointed at it?  I thought Sun was intending to
put Gnome2 into Solaris 10, they should have at least a few of their
thousands of people working on Gnome bugs.

Sun won't ship libgtop nor gnome-system-monitor with Solaris now so
that's why they aren't fixing this bug (rest assured that they are
fixing a lot of bugs in other modules :)

We just need to find someone with a Solaris box to look at this bug
(the gnome-system-monitor compile bug is simple to fix).

I've run into the same problem, and what I did to get around the
compile problems was to change the #ifdef LIBGTOP_VERSION_CODE to read

#ifdef LIBGTOP_VERSION_CODE >= 1001002 && LIBGTOP_VERSION_CODE < 2000000

This gets the compiles working in cpu.c, and several of the other
files that are required.  Until I can get a compiled build going,
I won't really know if these changes are functional, or just
hiding a problem.

I also hacked in a #define for GLIBTOP_MAX_GROUPS so that procdata.c
would compile.  These were easy fixes, but the one that will take
a little bit more resolution is to figure out where the linkage
dependency isn't getting referenced, as shown by this linker error:

Undefined			first referenced
 symbol  			    in file
_glibtop_init_hook_p               
/export/src/Garnome/garnome-0.21.2/gnome/libgtop/work/main.d/libgtop-2.0.1/sysdeps/solaris/.libs/libgtop_sysdeps_suid-2.0.sold:
fatal: Symbol referencing errors. No output written to .libs/mkinodedb2

*** Bug 106032 has been marked as a duplicate of this bug. ***

*** Bug 106045 has been marked as a duplicate of this bug. ***

Created attachment 14349 [details] [review]
Patch for compiling libgtop on Solaris 8 and 9

I looked at the original changes in the libgtop-1.1.2.1-solaris
and ported all the changes into the new framework.  It compiles
for both Solaris 8 and 9 (well, X86 anyway). The patch precedes this
note because I didn't realize that the patch would be uploaded as
a separate entity.

Follow on this build - 

u_int64_t is defined in config.h, but should probably live in
glibtop.h, since immediately following this successful build in
garnome, it broke gnome-system-monitor.

Is it appropriate to add this define using autoconf, and 
a glibtop.h.in to setup this define for other systems?

*** Bug 106109 has been marked as a duplicate of this bug. ***

Look at 104664.

The version of serveral files in the distributed tarball is antique. 
Isn't that the *real* problem?  Shouldn't it be possible to merge the
newer stuff into this package without breaking other builds, and still
get the Solaris stuff working a little better??

I picked out the latest version from CVS, and built it on my Solaris
box at home (x86) but that wasn't good.  Still, I believe our main
problem here is a version mismatch ....

It's mostly just data structures, and #defines that make up this
patch, with a fix for Solaris 9 shared memory variables that went
away in the change from Solaris 8 to Solaris 9.  The main data
structure that I added is for is in lib/sysdeps.c, and from my
read of the code, almost all the other architectures besides
Linux reference this data structure. 

My initial cut at fixing this was to do what you did, and change
the #ifdefs to leave out things.  However, that was going nowhere
fast, and then I found the old code that was for Solaris.  By
adding the appropriate #defines (adding to the 2.0.1 code as
opposed to changing the existing 2.0.1 code to match the
1.1.2.1-solaris code) to several of the .h files, and fixing a
few problems along the way, I finally got everything compiling
with the exception of a linker error for _glibtop_init_hook_p.
After reading through the code several times, and understanding
what this data structure does, I felt confident that this would
not impact Linux code, and I believe it has the possiblity of
improving the other systems which also use the _glibtop_init_hook_p.

I believe by only adding to the data structures, and #defines
to this code base, there should be little danger in breaking
other code trees.

Created attachment 14415 [details] [review]
patch for libgtop-2.0.1 to work with solaris 8 and 9

I tried the patch on my sparc solaris 8 machine, and the compile fails
at cpu.c:

In file included from ../../glibtop.h:37,
                 from cpu.c:24:
glibtop_machine.h:78:8: warning: extra tokens at end of #endif directive
In file included from cpu.c:31:
glibtop_private.h:68:8: warning: extra tokens at end of #endif directive
cpu.c:39: `GLIBTOP_XCPU_FLAGS' undeclared here (not in a function)
cpu.c: In function `glibtop_get_cpu_s':
cpu.c:84: structure has no member named `xcpu_flags'
gmake[3]: *** [cpu.lo] Error 1
gmake[3]: Leaving directory
`/home/poshea/usr/source/gnome2/libgtop-2.0.1/sysdeps/solaris'


BTW, what is the easy way to apply the patch on Solaris?  I had to do
it file-by-file.

On solaris, you need to use gpatch instead of patch (It's the Gnu patch).

The command to run is "gpatch -p0 < patchfile" above the libgtop-2.0.1
directory.  (I just verified the patchfile id-14415 patches the
current tree with the command I just gave you)

Ok, using GNU patch, it compiled fine (I must've missed patching a
file), except in the /doc directory where I got the following error:

Making info file `libgtop2.info' from `libgtop2.texi'.
libgtop2.texi:45: Unknown info command `dircategory'.
libgtop2.texi:46: Unknown info command `direntry'.
libgtop2.texi:51: Bad argument to `end', `direntry', using `format'.
libgtop2.texi:52: `@end' expected `ifinfo', but saw `format'.
./about.texi:11: Unknown info command `uref'.
./about.texi:11: Misplaced `{'.
./about.texi:11: Misplaced `}'.
./about.texi:26: Unknown info command `uref'.
./about.texi:26: Misplaced `{'.
./about.texi:26: Misplaced `}'.
./about.texi:30: Unknown info command `uref'.
./about.texi:30: Misplaced `{'.
./about.texi:30: Misplaced `}'.
./about.texi:90: Unknown info command `email'.
./about.texi:90: Misplaced `{'.
./about.texi:90: Misplaced `}'.
./about.texi:103: Unknown info command `uref'.
./about.texi:103: Misplaced `{'.
./about.texi:103: Misplaced `}'.
gmake[2]: *** [libgtop2.info] Error 2
gmake[2]: Leaving directory
`/home/poshea/usr/source/gnome2/libgtop-2.0.1/doc'

I assume this is harmless to the function of the libraries.

After compiling this and gnome-system-monitor (with highlander's patch
for system-monitor, in bug 106164) successfully, it all seems to work.

Is there some reason a new release of libgtop was made without this
patch in it?  What is needed to get this patch checked into CVS?

If it's working on Solaris with the patch and nothing else is affected
by it I'm sure it's no problem to put it in. Say yay or nay

*** Bug 105863 has been marked as a duplicate of this bug. ***

This patch causes problems for normal Linux users and thus needs to ge
reworked. I was kindly asked by Kjartan to test the patches, compile
and run some tests with it. Here the results:

1) patches apply seamless
2) configure and make process works perfectly
3) installing works perfectly
4) running gnome-system-monitor shows wrong values.

CPU and MEMORY show always '0'

Without this patch applied everything works normally on my Linux box,
memory and cpu content shown correctly. Patch applied against todays
(see date of my comment) anoncvs checkout (with correct branch) of
libgtop.

For further comments please contact me (email above and not on the cc
list).

Created attachment 18403 [details] [review]
Patch for compiling libgtop 2.0.2 under Solaris 8/9

(SunOS myhost 5.7 Generic_106541-25 sun4m sparc SUNW,SPARCstation-5)

Hi,

I'm new to GNOME Bugzilla. Just registered.

I have GNOME 2.2.x running on SPARC/Solaris 7,
compiled with gcc-3.2.2, on my SPARCStation 5.

So far without libgtop due to compile problems
similar to those reported in this Bug Report.

I've, some time ago, tried to compile libgtop
versions 2.0.0, 2.0.1, and 2.0.2 without success
:-(without applying any patches, because I just
   found out about their existance :-)

Now that 2.0.3 is out, I've just tried to build
that one too. Unfortunately this still fails.

My findings so far are the following:

1). during configure I got the following warning
    (otherwise it went through fine):

# ./configure


checking build system type... sparc-sun-solaris2.7

checking host system type... sparc-sun-solaris2.7

checking target system type... sparc-sun-solaris2.7

checking for a BSD-compatible install... ./install-sh -c

checking whether build environment is sane... yes

/tmp/libgtop-2.0.3/missing: Unknown `--run' option

Try `/tmp/libgtop-2.0.3/missing --help' for more information

configure: WARNING: `missing' script is too old or missing

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking for style of include used by make... GNU

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for suffix of executables... 

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking for gcc option to accept ANSI C... none needed

checking dependency style of gcc... gcc3

...

2). during the make stage the compilation of cpu.c failed,
    returning the following messages:

...
mv -f .libs/siglist.lo siglist.lo
source='cpu.c' object='cpu.lo' libtool=yes \
depfile='.deps/cpu.Plo' tmpdepfile='.deps/cpu.TPlo' \
depmode=gcc3 /bin/ksh ../../depcomp \
/bin/ksh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I../.. -D_IN_LIBGTOP -D_GNU_SOURCE -DGLIBTOP_NAMES -I../.. -I../..
-I../../sysdeps/solaris -I../../include -DNEED_GNOMESUPPORT_H
-I../../support -I../../support -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include   -g -O2  -I/usr/openwin/include 
-DGTOPLOCALEDIR=\"/usr/local/share/locale\"
-DLIBGTOP_VERSION=\"2.0.3\" -DLIBGTOP_SERVER_VERSION=\"5\"
-DLIBGTOP_VERSION_CODE=2000003
-DLIBGTOP_SERVER=\"/usr/local/bin/libgtop_server2\"    -g -O2 -c -o
cpu.lo `test -f 'cpu.c' || echo './'`cpu.c
rm -f .libs/cpu.lo
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP -D_GNU_SOURCE
-DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/solaris
-I../../include -DNEED_GNOMESUPPORT_H -I../../support -I../../support
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2
-I/usr/openwin/include "-DGTOPLOCALEDIR=\"/usr/local/share/locale\""
"-DLIBGTOP_VERSION=\"2.0.3\"" "-DLIBGTOP_SERVER_VERSION=\"5\""
-DLIBGTOP_VERSION_CODE=2000003
"-DLIBGTOP_SERVER=\"/usr/local/bin/libgtop_server2\"" -g -O2 -c cpu.c
-MT cpu.lo -MD -MP -MF .deps/cpu.TPlo  -fPIC -DPIC -o .libs/cpu.lo
cpu.c:39: `GLIBTOP_XCPU_FLAGS' undeclared here (not in a function)
cpu.c: In function `glibtop_get_cpu_s':
cpu.c:84: structure has no member named `xcpu_flags'
make[3]: *** [cpu.lo] Error 1
make[3]: Leaving directory `/tmp/libgtop-2.0.3/sysdeps/solaris'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/libgtop-2.0.3/sysdeps'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/libgtop-2.0.3'
make: *** [all] Error 2
#


It is surprising to me, because of the GLIBTOP_XCPU_FLAGS error,
that this error still remains in the new 2.0.3 distribution.
From what I can understand, by reading this Bug Report, that
problem has been spotted long ago (several releases) and even
has a patch submitted. It seems to me that the patch has still
not made it into the distribution 'tar.gz'. Is that right? If
so - why not?



Now, since I seem to have GNOME 2.2.x running on an ancient ;-)
platform, without libgtop though, I'm willing to verify the
functionality of the build process on the SPARC/Solaris (7)
platform IF SOMEONE is willing to merge the required patches
into the next release of libgtop, i.e. 2.0.4. But please act
soon, before I have lost focus again. I'm sorry that I won't
be able to help with the actual patching of the software due
to lack of time. :-(

Please contact me (email above and not on the cc list).



My next step is, when time allow, to try to apply the posted
patch, which is claimed to work for libgtop-2.0.2 on Solaris 8/9,
and see if it can be applied to libgtop-2.0.3 (on Solaris 7) too.

So, I guess, another reasonable (and leading) question would be;
do one need the patch when compiling libgtop-2.0.3 on Solaris 8/9,
and does it work (at least compile)? Or will there be a separate
patch for libgtop-2.0.3 on Solaris 8/9? If so, when?

Please let me know.

The patch submitted by Cory applies and works on version 2.0.3, at
least under Solaris 8 (on a SunBlade 100).  You'll need the GNU
version of patch instead of the native Solaris patch.

As for why this hasn't been given any attention by the maintainer in
over a year, that's a mystery.

Okay, Thanks!

I can hereby confim that the patch for libgtop-2.0.2 by Cory seems to
work for ligtop-2.0.3 too. At least after patching libgtop-2.0.3
builds with gcc-3.2.2 under Solaris 7 (on a SPARCstation 5).

I downloaded the patch and replaced all occurences of "libgtop-2.0.2"
with "libgtop-2.0.3" in the patch, and then followed the instructions
for patching given by the_h1ghlander@yahoo.com earlier in this thread.

Now, let's hope it finds it's way into the libgtop-2.0.4 tar ball.

*** Bug 116461 has been marked as a duplicate of this bug. ***

*** Bug 117808 has been marked as a duplicate of this bug. ***

I tried Cory's patch and it breaks binary compatibility, so it can't
go into the 2.0.x releases.

I tried it though on linux and it seems to work fine. Is there anyway
someone can rework it to not break compatibility? Otherwise it would
have to go into un unstable branch to be releases with GNOME 2.6

Applied to HEAD, you're responsible if you broke everything, thank you :)

2003-10-20  Bastien Nocera  <hadess@hadess.net>
                                                                     
         
        * include/glibtop/cpu.h:
        * include/glibtop/procstate.h:
        * include/glibtop/procuid.h:
        * include/glibtop/uptime.h:
        * lib/sysdeps.c:
        * sysdeps/names/cpu.c:
        * sysdeps/names/procstate.c:
        * sysdeps/names/procuid.c:
        * sysdeps/names/uptime.c: Apply patch by
the_h1ghlander@yahoo.com and
        Cory Omand <cory.omand@Sun.com> for Solaris support

*** Bug 104664 has been marked as a duplicate of this bug. ***

*** Bug 105864 has been marked as a duplicate of this bug. ***

Did the patches get into libgtop-2.5.0?  Because I still get compile
problems:

/home/poshea/usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_IN_LIBGTOP
-D_GNU_SOURCE -DGLIBTOP_NAMES -I../.. -I../.. -I../../sysdeps/solaris
-I../../include -DORBIT2=1 -threads
-I/home/poshea/usr/include/glib-2.0
-I/home/poshea/usr/lib/glib-2.0/include
-I/home/poshea/usr/include/libgnome-2.0
-I/home/poshea/usr/include/orbit-2.0
-I/home/poshea/usr/include/libbonobo-2.0
-I/home/poshea/usr/include/gconf/2
-I/home/poshea/usr/include/gnome-vfs-2.0
-I/home/poshea/usr/lib/gnome-vfs-2.0/include
-I/home/poshea/usr/include/bonobo-activation-2.0 -O3 -mcpu=ultrasparc
-I/home/poshea/usr/include -I/usr/openwin/include
-DGTOPLOCALEDIR=\"/home/poshea/usr/share/locale\"
-DLIBGTOP_VERSION=\"2.5.0\" -DLIBGTOP_SERVER_VERSION=\"5\"
-DLIBGTOP_VERSION_CODE=2005000
-DLIBGTOP_SERVER=\"/home/poshea/usr/bin/libgtop_server2\"
-I/home/poshea/usr/include -O3 -mcpu=ultrasparc
-I/home/poshea/usr/include -c cpu.c  -fPIC -DPIC -o .libs/cpu.lo
cpu.c:39: `GLIBTOP_XCPU_FLAGS' undeclared here (not in a function)
cpu.c: In function `glibtop_get_cpu_s':
cpu.c:84: structure has no member named `xcpu_flags'
gmake[2]: *** [cpu.lo] Error 1

*** Bug 125399 has been marked as a duplicate of this bug. ***

No, it will be in 2.5.1

Any ETA on 2.5.1?  Still waiting to test out the Solaris fixes.

Pretty please?  2.5.1?

Other packages, such as gnome-applets, now depend on libgtop>2.5.0. 
Not all of us have cvs access, some of us depend on package releases.

It's now been over three months since these fixes were committed, are
we going to get a release incorporating them soon?  

OK, Peter there is now a 2.5.1 release available. So sorry for taking
so long.

Trying out the new 2.5.1, I get this compile-time error:

 /home/poshea/usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../..
-D_IN_LIBGTOP -D_GNU_SOURCE -DGLIBTOP_NAMES -I../.. -I../..
-I../../sysdeps/solaris -I../../include -DORBIT2=1 -threads
-I/home/poshea/usr/include/glib-2.0
-I/home/poshea/usr/lib/glib-2.0/include
-I/home/poshea/usr/include/libgnome-2.0
-I/home/poshea/usr/include/orbit-2.0
-I/home/poshea/usr/include/libbonobo-2.0
-I/home/poshea/usr/include/gconf/2
-I/home/poshea/usr/include/gnome-vfs-2.0
-I/home/poshea/usr/lib/gnome-vfs-2.0/include
-I/home/poshea/usr/include/bonobo-activation-2.0 -O2 -mcpu=ultrasparc
-I/home/poshea/usr/include -I/usr/openwin/include
-DGTOPLOCALEDIR=\"/home/poshea/usr/share/locale\"
-DLIBGTOP_VERSION=\"2.5.1\" -DLIBGTOP_SERVER_VERSION=\"5\"
-DLIBGTOP_VERSION_CODE=2005001
-DLIBGTOP_SERVER=\"/home/poshea/usr/bin/libgtop_server2\"
-I/home/poshea/usr/include -O2 -mcpu=ultrasparc
-I/home/poshea/usr/include -c procargs.c  -fPIC -o .libs/procargs.o
procargs.c: In function `glibtop_get_proc_args_s':
procargs.c:63: warning: passing arg 1 of `g_malloc' makes integer from
pointer without a cast
procargs.c:63: error: too many arguments to function `g_malloc'
procargs.c:71: warning: passing arg 1 of `g_malloc' makes integer from
pointer without a cast
procargs.c:71: error: too many arguments to function `g_malloc'
gmake[3]: *** [procargs.lo] Error 1
gmake[3]: Leaving directory
`/home/poshea/usr/source/gnome2.4/libgtop-2.5.1/sysdeps/solaris'

Looking a little deeper, and excuse me if I'm missing something
obvious, but in glib-2.3.2/glib/gmem.c, g_malloc seems to have only
one argument.  But if I look in
libgtop-2.5.1/sysdeps/solaris/procargs.c lines 63 and 71, g_malloc is
being called with two arguments:

	   	ret = g_malloc(server, max_len + 1);
and 

	   ret = g_malloc(server, len + 1);


How does this code compile for anybody else?  I can't be the only
person trying it on Solaris.

Hello Peter,
I'm reading this by accident, and I'm the second person building GNOME for Sol :)
In 2.6.0, the calls you're referencing have only one argument.

...
       if(max_len)
        {
                ret = g_malloc(max_len + 1);
                if(max_len < len)
                        len = max_len;
                memcpy(ret, pinfo.pr_psargs, len);
                ret[len] = 0;
        }
        else
        {
           ret = g_malloc(len + 1);
...