2.3  How do I switch CDE's window manager to use WindowMaker?

Method 1:

Peter Ilberg gives us this answer:

Install WM wherever you want it, mine is in /opt/WindowMaker-0.16.0 (eg. use ./configure --prefix=/opt/WindowMaker-0.16.0). Run the install script wmaker.inst in your home directory.

Add the following two lines to .dtprofile in your home directory:

	SESSIONTYPE=xdm; export SESSIONTYPE
	PATH=:/usr/contrib/bin/X11:$PATH:.; export PATH

This tells CDE to go looking for an .xinitrc/.xsession instead of using the default environment.

Make your .xsession/.xinitrc executable (VERY IMPORTANT, wmaker.inst did NOT do this automatically for me) using eg.

	chmod ugo+x .xsession

Your .xsession/.xinitrc should look something like this:

	#!/bin/sh

	<some other init stuff that you want/need>

	exec wmaker

Things to try if it doesn't work: (somewhat fuzzy and random)

This should do it although I did have problems sometimes initially which I fixed by randomly trying absolute pathes for wmaker in .xsession/.xinitrc and/or making the dtprofile/.xinitrc/etc executable. It helps logging in on the console (select from CDE login screen) and start X manually using "X". If it works that way it should work when logging into the CDE environment. Remember to Check your paths!

If it doesn't work, you can also substitute some other window manager for wmaker in the .xinitrc and see if that works. If it does you know at least that .xinitrc is getting called/executed, so your WM path is wrong or not set.

Method 2:

Thomas Hanselman gave this alternative answer (via Peter Ilberg):

Build and install WM wherever you want, as described in Method 1. You can install and run WM just fine from your home directory. That's what I'm doing, since I don't have root access at work :(. Then, in your Xdefaults file in your home directory, add the following line:

	Dtsession*wmStartupCommand: <path to WindowMaker executable>

Then, log out, and log back in, and, unless I've forgotten a step (or this is a custom Nortel thing), you should be in Window Maker heaven ;).

Difference between the methods: (according to Thomas)

I've been told that the difference between setting the resource and Peter's method is that if you override the window manager with the resouce, you still get the CDE resources read into the resource database (so you still have your color settings & such from CDE), whereas with Peter's, the CDE resource don't get read into the database. I don't know if this is true or not, however. Also, another thing to note with Window Maker and HP-UX 10.20 -- if you select "Exit Session" from the WM root menu, WindowMaker and all of your applications are killed, but you may not be logged out. Again, this might be an artifact from my work environment, or the way I start Window Maker.

Owen Stenseth adds:

When using this method it is possible to exit Window Maker cleanly by using the dtaction command. I use the following in my Window Maker menu:

            "Exit Session"      EXEC dtaction ExitSession

The only problem I have at the moment is I seem to get multiple copies of asclock running when I log in again.

2.4  Do I need to rerun wmaker.inst with every new version of Window Maker?

Dan Pascu reveals the answer:

If this is necessary, it will be listed in the NEWS file included in the source distribution. Since 0.15.x, the domain files have been changed in such a way that re-running wmaker.inst is redundant. The user config files are by default merged in with the global ones normally located in /usr/local/share/WindowMaker/Defaults. So, even if new options are added, they should be automatically added to the environment.

2.5  Why am I only getting a root menu with xterm and exit items?

Most likely, the problem is that Window Maker can not find a copy of the C pre processor in a directory such as /lib. The file /lib/cpp should be a symbolic link to whatever C compiler's cpp you are using. For example:

	cpp -> /usr/bin/cpp-2.95*

Another possibility is your /usr/X11/lib/X11/xinit/xinitrc is a broken symlink. Either create a new symlink, or do something like:

	$ cp /usr/X11/lib/X11/xinit/xinitrc.fvwm2 \
		/usr/X11/lib/X11/xinit/xinitrc.wmaker

	$ ln -sf /usr/X11/lib/X11/xinit/xinitrc.wmaker \
		/usr/X11/lib/X11/xinit/xinitrc

then just edit /usr/X11/lib/X11/xinit/xinitrc and replace the exec of 'fvwm2' by '/usr/local/bin/wmaker' (should be somewhere towards the end of the file, most probably the very last line).

Thanks to Tomas Szepe for the second part.

2.6  How do I get Window Maker to use more than 16 colors on my SGI Indy Workstation?

Thanks to Peter H. Choufor this answer:

By default, the SGI X Server uses 8-bit Pseudocolor mode. To change it, edit (as root) the file /usr/lib/X11/xdm/Xservers. Change it to read:

    :0 secure /usr/bin/X11/X -bs -c -class TrueColor -depth 24

2.7  Using WindowMaker with Solaris 2.6 CDE

Thanks to Rob Funk for this answer:

Assuming you installed Window Maker according to the README's that come with the source, all you need to run Window Maker on a Solaris box is an entry in the .xinitrc. This should work for any version. When you run wmaker.inst the first time, allow it to make changes to the .xinitrc file. Mine looks like this:

 #!/bin/sh
 # Window Maker Default .xinitrc
 exec /usr/local/bin/wmaker

Believe it or not, that's all that it takes. This, in fact, runs Window Maker instead of OpenWindows. In order to choose Window Maker, you simply choose "OpenWindows Desktop" in the "Options - Session" Menus And Choose "CDE Desktop" if you want CDE.

The color schemes and settings for Window Maker are seperate from CDE. I tested on a SPARC 10, but I assume Solaris x86 would work also.

(webmaster note: It works fine on Solaris x86)

2.8  How do I install Window Maker on a Solaris box?

Here are some hints from John Kemp:

Installing Window Maker on a Solaris 2.6 box might require one or two little hints. Here you are (this was on a system running xdm by the way, but similar suggestions apply otherwise):

1) /usr/openwin/lib/X11/xdm/Xservers like this:

:0 local /usr/openwin/bin/X -dev /dev/fb defdepth 24 defclass TrueColor

2) Turn off shm in the WindowMaker configure:

./configure --disable-shm

3) might have to modify your LD_LIBRARY_PATH:, or make "wmaker"

   a script that does it for you (mv wmaker wmaker.exe):

LD_LIBRARY_PATH=/usr/local/lib:/usr/local/X11/lib:/usr/lib:/usr/openwin/lib export LD_LIBRARY_PATH /usr/local/bin/wmaker.exe $*

The real key is the "--disable-shm".

(webmaster note: Window Maker should work fine with SHM enabled, at least it does under Solaris 8. Try the default first, and then use this if you run into problems with it)

2.9  How do I fix an error such as libwraster.so.1: cannot open shared object file?

If you have an error when running Window Maker such as

	libwraster.so.1: cannot open shared object file

These are the instructions for Linux.

First, make sure that /usr/local/lib ( or whatever directory you installed Window Maker to) is listed in your /etc/ld.so.conf ). You need to run ldconfig so the new shared libraries will be loaded. After running ldconfig as root, the linker should properly load the libraries. You need to run this every time you update Window Maker.

Thanks to Joseph Czapiga, the BSD procedure for adding shared library directories is

	ldconfig -m /usr/local/lib  (m means merge)

2.10  How do I fix an error dealing with aclocal: configure.in: 15: macro 'AM_PROG_LIBTOOL' not found in library?

You need to install libtool. It also must be a libtool different from version 1.2b ( shipped with redhat 5.2 ). You can get libtool from ftp.gnu.org/pub/gnu Make sure the autoconf and automake versions you have installed are at least: autoconf 2.12 automake 1.3 libtool 1.2

 From Blaine Horrocks:

"You can also work around this problem on RedHat5.2 by copying the distributed aclocal.m4 to acinclude.m4 before running configure for the first time. Configure works fine and doing the make succeeds."

2.11  When I run wmaker, it quits complaining about '__register_frame_info'

This is related to having compiled Window Maker on a system whose libraries were compiled by egcs or gcc 2.8.0, and then using the binaries on a system whose libraries were compiled by gcc 2.7.2.x

Try compiling Window Maker with the newer gcc or recompile your system libraries with the older gcc. It's generally a bad idea to mix and match.

2.12  How do I make libjpeg link against Window Maker?

The newest jpeg libs are availible at http://www.ijg.org

How many of you have seen that darned "lib reports 62 caller expects 61" type of error? Here are some answers that will possibly help you out.

First things first. As always, make sure there are not older copies of libjpeg floating around on your system. ]Some distributions by default come with an old libjpeg.so.1 in the /usr/X11R6/lib/ directory. This can simply be deleted. Or if something complains after you delete it, recompile it if you can to look for the new lib in the right place, or if that fails, as a last resort, you might add a symlink to the new lib like so: ln -s /usr/local/lib/libjpeg.so.6.0.2 libjpeg.so.1

Note that you should use your system's version of ldconfig to properly manage your library cache (or other appropriate mechanism).

On Linux, this would mean having /usr/local/lib in /etc/ld.so.conf and then running ldconfig.

Now on to the error. This is basically caused by your application having been compiled to dynamically use the libjpeg.so shared library. When you install a new lib and then try to run your program again, it expects the lib it was compiled against, in this case the older libjpeg.so.6.0.1 and instead finds libjpeg.so.6.0.2 and reports the error.

The fix is actually rather simple. Along with adding a libjpeg.so.6 symlink like so (just in case): ln -s libjpeg.so.6.0.2 libjpeg.so.6 where you installed your new lib, you simply need to recompile your app to link it against the new library.

Also, make sure to use GNU make for the Window Maker compile.

2.13  How do I start Window Maker after running wmaker.inst?

As of version 0.53.0, the wmaker.inst script will modify your X startup script ( .xinitrc or .Xclients or .Xsession ) to do something thats (hopefully) appropriate.

In order to run wmaker, a user needs to have an ~/.xinitrc file consisting of something similar to

	#!/bin/sh
	exec wmaker

This will vary from system to system, but the existance of an .xinitrc file will generally override the system defaults.

2.14  How do I make libpng link against Window Maker?

The newest png libs are availible at http://www.libpng.org/pub/png/libpng.html

You should also get the newest zlib libs from http://www.gzip.org

Generally, the same rules apply here as with libjpeg. Make sure there are no older versions of the necessary libs floating around on your system, then try to configure and make again.

Also, make sure to use GNU make (gmake) for the Window Maker compile.

2.15  How do I make giflib or libungif to link against Window Maker?

The newest versions of both these libraries are available at http://prtr-13.ucsc.edu/~badger/software/ Users have had a few problems with giflib... it seems that the install process didn't install the header file libgif.h, so although the Window Maker configure found the lib (libgif.so.x), when you actually try to compile, it fails when it looks for the header to include the make. One solution is to simply copy it from the libgif source directory to the local system include directory. (/usr/local/include/ on many systems).

Also, make sure to use GNU make (gmake) for the Window Maker compile.

2.16  How do I fix an error similar to "wrlib: could not allocate shared memory segment: invalid argument"

This relates to a shared memory problem on Solaris. Usually one can't see it - but it is visible if X is started from command line (or fail-safe session for that matter). In any of the cases, on the stderr you get an error message like this:

	 "wrlib: could not allocate shared memory segment: invalid argument"

This one is generated by wrlib if Window Maker is compiled with shared-memory usage enabled (which is the default). The explanation is that Solaris by default comes with a shared memory segment size of maximum 1 M. What happends is that if you have a really-really cool(tm) background, it is usually much bigger than that 1 M segment of shared memory. To see your defaults relating the IPC settings check the output of the "sysdef" command (look for IPC Shared Memory). There you should see the maximum allocable size for a shared memory segment. If it is less than 5 M you should really increase it by adding the following line in your /etc/system file:

	set  shmsys:shminfo_shmmax=20971520 

*) Make sure you don't already have this value set. If you do, simply increase the value. In case you have a much bigger value, stick to what you have, because you should have no problems with it.
*) The value allows a maximum segment size of 20 M, which really should be enough for anyone. If not, try using a smaller background image!
*) Make sure you spell the line exactly as shown, otherwise at boot time the kernel will complain of not finding such a module name and will not set a thing about it!
*) Make sure you don't delete other lines or modify them "beyond recognition", for evil things may happen at boot time.

After adding this to your /etc/system you need to reboot in order for the new limit to take effect. Also, you may want to check the new limit just to make sure it has been set.

Thanks to Bogdan Iamandei for this answer.

2.17  How do I add Window Maker to the Solaris dtlogin screen?

The two files that determine alternate window managers are:

	/usr/dt/config/C/Xresources.d/Xresources.*
	/usr/dt/config/Xsession.*

If you look in there, you'll find Xresources.ow and Xsession.ow, respectively. All you need are two files that set up Window Maker (or any other window manager) in a similar fashion, calling them Xresources.wm and Xsession.wm (or whichever extension you prefer).

Here is an example setup:

	#
	**************************************************************************
	#
	# Window Maker config file
        # Mike Bland <mbland@cmu.edu>
     	#
	# /usr/dt/config/C/Xresources.d/Xresources.wm
	#
	# used by dtlogin
	#
	#
	**************************************************************************

	Dtlogin*altDtsIncrement:        True

	Dtlogin*altDtName:      Window Maker
	Dtlogin*altDtKey:       /usr/local/bin/wmaker
	Dtlogin*altDtStart:     /usr/dt/config/Xsession.wm
	#Dtlogin*altDtLogo:     /usr/local/share/logos/WM_logo.xpm

	# Once I get a logo ready, I'll add it to the dtlogin screen by
	uncommenting
	# the last line.

And this example script:

	#!/bin/ksh
	#
	**************************************************************************
	#
	# Window Maker startup script
        # Mike Bland <mbland@cmu.edu>
	# /usr/dt/config/Xsession.wm
	#
	# used by dtlogin
	#
	#
	**************************************************************************

	. /usr/local/etc/.profile       # Sources the file containing necessary
	                                # environment variables (especially
	                                # LD_LIBRARY_PATH=/usr/local/lib:...);
        	                        # make sure it's executable.

	WINDOW_MANAGER=/usr/local/bin/wmaker

	export WINDOW_MANAGER

	/usr/local/bin/wmaker

2.18  What happened to libPropList?

The libPropList dependency has been removed as of Window Maker version 0.70.0, and is replaced by cleaner, more robust code in the WINGs toolkit. This new code maintains existing proplist compatibility, so there are no visable changes for users, and existing file formats will work as they did before.

For developers, there is a proplist-compat.h header that provides a mapping between the old and new function names. See the comments in this file for further instructions.

 

---

  Top-level of FAQ