Content

  1. Xew 4.0 default installation
  2. Tailored installation using configuration parameters
  3. Manual configuration
  4. X11R4 configuration
  5. Openwin and Solaris
  6. Installed library problems

Xew 4.0 default installation

The default installation will build Xew, demo and X Print Server (Xp) using the defaults of your system. It will automaticly include support for JPEG, TIFF and RLE, if it can find the libraries. The default will not use MOTIF subclassing.

Retrieve the packages

Unpack Xew-4.0.tar.gz and Xew-4.0-Xp.tar.gz in your chosen directory. Each of the packages will unpack into directory "./Xew-4.0/" and will create one or more subdirectories under it.

	zcat package.tar.gz | tar xvf -

Xew-4.0 comes with GNU autoconf generated ./configure script. After unpacking, the simplest configure and installation steps are

  1. cd Xew-4.0
  2. ./configure
    or
    ./configure --with-motif
  3. make
  4. make test

'make test' attempts to run 'demo/texted' and X print server (Xp/pserver), if compiled. You need X Window DISPLAY to run the test.

If you want to install Xew into your system directories (root required usually), you need to

  1. cd Xew
  2. make install
  3. make install.includes (if 'make install' did not do this)

Tailored installation using configure parameters

If this simple installation did not give the result and features you require, you need to read more of this document and rerun the configure with additional switches.

Use
./configure --help
to find out about the supported switches in the configure script (this document may not always be quite up to date).

Warning!
The configure script is generated by GNU autoconf 2.7. This version still has the bug that causes problems, if you try to specify a library that has '-' in the name (thus, "-ljpeg-6" is not going to work).

--with-motif[="C compiler options"]

Xew widgets can optionally be compiled as subclassed from the Motif XmManager. This configuration parameter enables the Motif subclassing. The C compiler options are optional and can be used to specify non-standard paths for the Motif includes (-I..) and library (-L..). This switch adds

-DUSING_MOTIF_122
definition into Xew builds.

The default is to compile Xew without MOTIF.

--with-local[="C compiler options"]
--with-jpeg[="C compiler options"]
--with-tiff[="C compiler options"]
--with-rle[="C compiler options"]
--without-local
--without-jpeg
--without-tiff
--without-rle

You need to use above flags if the default configuration did not find the libraries (--with), or it did find some, and you do not want to include them (--without).

The use of JPEG, TIFF or RLE packages requires that the following files exist

- from jpegsrc.v5 (or later)
/usr/local/include/jpeglib.h
/usr/local/include/jerror.h
/usr/local/include/jconfig.h
/usr/local/include/jmorecfg.h
/usr/local/lib/libjpeg.a
- from tiff-3.2beta.tar.Z (or later)
/usr/local/include/tiff.h
/usr/local/include/tiffio.h
/usr/local/lib/libtiff.a
- from utah raster toolkit
/usr/local/include/rle.h
/usr/local/include/rle_code.h
/usr/local/include/rle_config.h
/usr/local/include/rle_raw.h

If your includes and libraries were already in /usr/local/include and /usr/local/lib, then the default configure should already have found them. If your common shared includes are in some different place, you can override /usr/local assumption with

--with-local="-I<your-include-path> -L<your-library-path>"
The '--with-local' can be used with any number of -I and -L options.

If TIFF, JPEG or RLE libraries are installed into non-standard places, you can also specify indivially for each of them

--with-jpeg="-I<jpeg-include-path> -L<jpeg-library-path>"
--with-tiff="-I<tiff-include-path> -L<tiff-library-path>"
--with-rle="-I<rle-include-path> -L<tiff-library-path>"

Additionally, if any of the libraries have non-standard name (other than 'jpeg', 'tiff' or 'rle'), you can also add "-l<library-name>".

--with-dolibs[="[-]normal [-]debug [-]profiled [-]shared"]

The template Imakefiles (Imakefile.in) will usually build all libraries (normal, shared, debugger and profiled) which Imake environment indicates being possible. Unfortunately, it quite often happens that regardless of the apparent support, the actual library templates are not working correctly in many installations. For this reason, the configure script will by default override the Imakefile and force only the NormalLib to be built.

By specifying a plain --with-dolibs you can restore the default Imakefile build (configure will not override anything). Or, you can individually enable or disable specific library builds. For example --with-dolibs="-shared" will disable shared library build, but uses the defaults for others.

Note:
Forcing a build of a library type that your environment does not support will not work, and will result compilation problems during the make. Thus --with-dolibs=shared will not magically produce shared libraries, if the system and imake environment does not support them.

--with-print[="C compiler options"]
--with-xprinter[="C compiler options"]

You can only specify either one of these or none.

Neither (the default)
if the build directory has a subdirectory "./Xp", the configure assumes this directory contains the X Print Server library and client includes, that will be built along with the other things. The definition -DUSING_PRINTSERVER is added to the compile flags.
--with-print
if the X Print Server library is already installed in some other place. The configure will not test the existence of the ./Xp directory, but will test the existence of the library (with function XSetPrintParams). The definition -DUSING_PRINTSERVER is added to the compile flags.
--with-xprinter
if you are using the Xprinter printing library from Bristol Technology Inc. The definition -DUSING_XPRINTER is added to the compile flags.

--with-xmu[="C compiler options"]
--with-xaw[="C compiler options"]

Athena (Xaw) and Xmu libraries and includes are usually included in the normal X environment, but if you have them installed in a non-standard place, which is not already covered by other configurations (such as --with-local), then you can add the necessary compiler options with these switches.

The build of ./Xew does not use or need Athena, but it does need some Xmu include files.

--with-xew[="C compiler options"]

By default the configure script assumes that the ./demo and other possible application directories will be using the Xew buing built in the current directory.

The switch allows you to override this assumption. A simple --with-xew (without any arguments) will just override, and force the application to use the installed Xew from the standard location. Use specific compiler options (-L, -I, -l) to use non-standard locations.

This switch does not affect the ./Xew build process.

--without-shmem
--with-shmem

By default the configure script assumes the support for MIT Shared Memory can be compiled into Xew, if the header <sys/shm.h> exists, and adds -DSH_MEM into compile options in that case.

Specifying --without-shmem will prevent this test and does not specify any compile options. This is useful, if you have the header tested by the default configuration, but get compilation problems due to this.

Specifying --with-shmem sets -DSH_MEM explicitly without testing anything (not very useful).

--with-debug[="C compiler options"]
--without-debug

Will override CDEBUGFLAGS in demo/Imakefile (and other application files). Normal default for CDEBUGFLAGS is taken from Imake DefaultCDebugFlags. This switch does not affect ./Xew building.

--with-debug
sets CDEBUGFLAGS to DebuggableCDebugFlags.
--without-debug
sets CDEBUGFLAGS to OptimizedCDebugFlags (this is what the DefaultCDebugFlags is set to usually, normally you don't need to use this).
--with-debug="options"
sets CDEBUGFLAGS to the specified options string.

--with-im[="C compiler options"]

The only special input method supported by Xew is BIG5 through something that is called "xcin" (the support for this was provided by You Shung-I <daniel@info1.csie.nctu.edu.tw>). Using this switch adds
-DIM_XCIN
definition into Xew builds. You will probably need to specify additional include and library paths.

--with-cc="cc command"
--with-cdebugflags="C compiler options"

May work as a last ditch solution, if your C compiler and installed Imake environment do not match (typical with "out of box Solaris", which comes configured to use the Sun cc, but which is not present unless you bought it)

Examples

./configure --with-cc=gcc --with-cdebugflags="-O -Wall"
./configure --with-cc="cc -Aa -D_HPUX_SOURCE" --with-cdebugflags=-O

Manual configuration

If the ./configure script fails, all hope is not lost yet. You can still

  1. copy the Imakefile.in in each subdirectory into Imakefile, and use it as is, or after manually editing it to fit your needs. Imakefile.in's are written for minimal requirements and defaults.
  2. or, just run ./configure with closest approximation of switches you can find, then edit the generated Imakefile's.

In both cases, after editing the Imakefiles, you proceed in each subdirectory as with any X package that comes with Imakefile

  1. cd subdirectoy
  2. xmkmf -a (or 'xmkmf; make includes; make depend')
  3. make
  4. make install (if applicable, to install libraries)
  5. make install.includes (if applicable, sometimes 'make install' already does this)

X11R4 configuration

If you try to compile this under X11R4 you may have to manually tweak the Imakefiles. At least Apollo sr10.2/R4 had two problems:

  1. 'make includes' tried to use 'mkdirhier.sh' instead of 'mkdirhier'. Can do 'make install.includes' instead and use the installed includes or try uncommenting the MKDIRHIER definition in Imakefile].
  2. 'make install.includes' does not actually create the X11/Xew *directory*. Had to create the directory by hand. WATCH OUT FOR THIS! It creates a *file* X11/Xew!

Note
I do not have any X11R4 system available at this point. This release is not tested under X11R4.

Openwin and Solaris

Because out of box Solaris configuration does not include a C compiler, but the Openwin Imake configuration will, however, assume that the Sun C compiler is used, the resulting Imakefiles from configure are not very useful, even if you have Gnu C installed (and configure finds it). To get things work, you must change the Imake environment to use GCC (site.def), or try to patch things using the --with-cc and --with-cdebugflags override switches, for example

./configure --with-cc=gcc --with-cdebugflags="-O -Wall"

If above is not enough, you need to do some further hacking by editing the produced Imakefiles, or even Makefiles.

  1. you might need to define OPENWINHOME environment,
  2. 'make includes' fails. add line 'MKDIRHIER = mkdirhier' into Imakefile

Installed library problems

One of the nastiest things you may run into, is the situation where you already have one of the libraries (Xew or Xp) installed on your system directories, but want to use the new version in the build directory. The situation is nasty, because you may spend a lot of time trying to figure out why things work differently than you expect, without realizing that you are still using some old library. Beware!

In some Imake configurations (X11R6), there exists a make symbol LDPRELIB, which is set to the default X11 library path, and which in linking command prefixes all other libraries. The ./configure script attempts to nullify this, by exlicitly setting this to empty, if Xew or Xp in build directory is to be used.

With Sun openwin (and X11R5?) Imake environment there is no such symbol, but the system library is explicitly inserted after the link options. In such case you need to edit the Makefile manually before running 'make' again: find the LDOPTIONS setting and remove the "-L$(USRLIBDIR)" from the end of the definition.

Unfortunaly, this only solves half of the problem in shared library environments (such as SunOS, Solaris). When you run applications, it will still use the system version of the libraries, unless you change the LD_LIBRARY_PATH (on Suns) to have the new library location searched before the system libraries.


© 1995 Markku Savela