Thanks for this:
> I needed
>
> #include <stdint.h>
>
> in util.c (as suggested in the comment) for the definitions of
> uint16_t and uint32_t. No problems running the new ctwm so far
> (System: openSUSE 12.3 (x86_64) 3.7.10-1.16-desktop).
I think I would have been completely stuck without that hint. (I am not a C
programmer, though I know enough to use that tip. See below.)
My story:
Running Fedora 19, 64 bit
3.13.7-100.fc19.x86_64 #1 SMP Mon Mar 24 21:53:16 UTC 2014
-------
FIRST PROBLEM:
missing files in /usr/include/gnu
stubs-64.h
stubs-32.h
solved by tip found using google:
yum install glibc-devel.x86_64
(I suppose many programmers would already have that installed. But I didn't.
Could the installation files check for this?)
SECOND PROBLEM:
gram.tab.c
gram.y:85:31: fatal error: X11/Xmu/CharSet.h: No such file or directory
# include <X11/Xmu/CharSet.h>
Package libXmu-1.1.1-4.fc19.x86_64 already installed and latest version
Solved by
yum install libXmu-devel
Similar problem solved by
yum install libXpm-devel
-------
THIRD PROBLEM
util.c:3918:1: error: unknown type name 'uint16_t'
uint16_t *buffer_16bpp;
^
util.c:3919:1: error: unknown type name 'uint32_t'
uint32_t *buffer_32bpp;
^
util.c: In function 'LoadJpegImage':
util.c:4015:18: warning: assignment from incompatible pointer type [enabled by
default]
buffer_16bpp = (unsigned short int *) malloc ((width) * (height) * 2);
^
make: *** [util.o] Error 1
I was completely stuck -- with no help from google, until I saw the message
From: Tadziu Hoffmann <[email protected]>
So in util.c, after
#ifdef JPEG
I inserted:
#include <stdint.h>
Then 'make' completed, somewhat to my surprise!
So I made a symbolic link from /usr/local/bin/ctwm to the new ctwm binary,
terminated ctwm (with X still running, making sure I had a convenient xterm
window with shell prompt.),
Invoked ctwm, and instantly all my workspaces etc. came back and for the last
30 minutes or so it has all worked perfectly.
I am left wondering where all the information about workspaces, mappings of
windows to workspaces, locations on the screen, whether minimised or not, etc.
was stored while ctwm was not running. I had assumed the data-structures were
maintained by ctwm.
The only thing that was not preserved was the stacking order of windows as shown
in the iconmanager. I noticed some changes though they don't affect performance.
Presumably it will survive hibernate/resume also. (I hardly ever shutdown
and reboot, except after kernel update.)
Presumably all this means it should be straightforward for someone to build
fedora rpm files. Is the previous fedora rpm builder on this mailing list?
Later I'll try this in Fedora 18, on my laptop.
I am amazed at how small ctwm is, as shown by 'top'.
Thanks to everyone concerned.
