4.62 Release Notes for SGI IRIX Computers

Back to 4.62 Release Notes.
Rev: March 5, 1999

CONTENTS

    I.    FEATURES THAT AFFECT SGI USERS
    II.   IRIX, C, and FORTRAN VERSIONS
    III.  OBJECT-CODE FORMATS FOR RELEASES 5.X and 6.X OF IRIX
    IV.   KERNEL RECONFIGURATION FOR DATABASE SERVERS -- IRIX 5.X
    V.    KERNEL RECONFIGURATION FOR System V IPC -- IRIX 5.X
    VI.   KERNEL RECONFIGURATION FOR 64-bit Merlinserver ON IRIX 6.X
    VII.  SHARED OBJECTS and RUNTIME DYNAMIC LINKING

---------------------------------------------------------------------------

I.   FEATURES THAT AFFECT SGI USERS

The following shell scripts are provided to run XView programs under SGI's
default "4dwm" window manager;

   xvmerlin4d
   xvpcmodels4d
   xvthor4d
   sgi4d

This scripts are supported but are no longer absolutely required.  Changes
to the Daylight "Options Manager" system allows automatic adjustment of
options which are window-environment specific (details below).  In most
cases, the user environment can be arranged so that these scripts are not
needed.  You may safely stop using the "4d" scripts under these conditions:

   o  you are not using SGI's default "4dwm" window manager, OR
   o  your client programs are running on an IRIX operating system, OR
   o  you have set the environment variable DY_WINDOW_ENVIRONMENT to SGI_4DWM

   AND

   o  you are willing to set your default font as described below.

If you stop using the "4d" scripts, you must add a line similar to this to
your X Resources database (i.e. to the file $HOME/.Xdefaults):

   Font.Name: -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1

Without this specified, XView programs will work correctly, but fonts used
for titles and buttons may be big and ugly.  This normally takes effect when
you start X-Windows.  To make this change effective immediately, enter:

   $ xrdb $HOME/.Xdefaults

An example .Xdefaults that contains this line can be found in
$DY_ROOT/contrib/home/sgi/.Xdefaults.

Background:

   A bug in the IRIX X Window system combined with bad habits in Sun's XView
   code caused the IRIX window system to "lock up" when Daylight applications
   were run.  In addition, many of the default options (such as fonts, and
   graphics parameters) had to be changed for optimum performance when running
   under SGI's default window manager "4dwm".

   To solve this, Daylight supplies a set of "wrapper" scripts, "xvmerlin4d",
   "xvthor4d", and "xvpcmodels4d", that invokes XView programs with parameters
   appropriate for use with IRIX X-servers and the 4dwm window manager.

With release 4.33 and later ...

   These features are added to the Daylight "Options Manager" package:

   1. A new "#if/#else/#endif" feature was added to the Daylight options
      manager.  This allows selective processing of options.

   2. If the environment variable DY_OPERATINGSYSTEM is not defined at
      runtime, the Daylight options manager will automatically set it to
      the client's operating system (e.g., "IRIX", "SunOS", "HP-UX").

   3. A new version of dy_sysprofile.dat is provided as a suggested
      system profile.  This file uses the new "#if" feature to set up
      O/S- and window-specific options from environment variables
      DY_OPERATINGSYSTEM and DY_WINDOW_ENVIRONMENT.  Options for these
      environments are provided: SGI_4D, HP_VUE, MAC_X, and SUN_OLWM.

      The file dy_sysprofile.dat sets default SGI_4D option values for IRIX
      operating systems, HP_VUE values for HP-UX, SUN_OLWM values for SunOS.
      These values will be overridden if the DY_WINDOW_ENVIRONMENT variable
      is defined.  The MAC_X environment must be specified when needed.

---------------------------------------------------------------------------

II. IRIX, C, and FORTRAN VERSIONS

Daylight software runs on version 5.X and 6.X of IRIX.

To find out what version you are running, use:

   % uname -r
   5.3


Daylight Toolkit customers must be sure they have the rev. 3.10 SGI FORTRAN
and/or C compilers.

To see what version of the compilers you have, use the versions(1) command
and look for the 3.10 Maintenance line:

   % versions | grep 'Ansi C'
   I  c                    08/21/91  Ansi C 1.1
   I  c.man                08/21/91  Ansi C Manual Pages
   ...
   I  maint_c              09/07/92  Ansi C Maint, 3.10
   ...


   % versions | grep Fortran
   I  eoe1.sw.lib          10/30/92  Execution C/Fortran Libraries
   I  ftn                  03/05/92  Fortran 77, 3.4.1
   ...
   I  maint_ftn            09/07/92  Fortran 77 Maint, 3.10
   ...

---------------------------------------------------------------------------

III. OBJECT-CODE FORMATS FOR RELEASES 5.X AND 6.X OF IRIX

This version of the Daylight system has been compiled under IRIX 5.X and has
been tested on both version 5.X and 6.X.  A single set of binaries, which run
under all IRIX5 and IRIX6 machines (on R4000 or newer CPUs) is distributed.
For users of the toolkit libraries, the situation is complicated by the
object file formats.

In order to support 64-bit native systems, SGI has once again changed its
object code (.o) file formats.  Under IRIX 6.X, SGI supports three separate
object file formats:  'old 32-bit', 'new 32-bit' and 64-bit.
 
The SGI C and Fortran compilers and linker can generate all three object
format files.  SGI supplies system libraries in all three formats.
 
Format     Compiler flag     System Library path
 
old 32-bit     -32               /usr/lib
new 32-bit     -n32              /usr/lib32
64-bit         -64               /usr/lib64
 
SGI now uses three environment variables for the dynamic linker:
 
LD_LIBRARY_PATH:    old-format 32-bit shared library path (/lib:/usr/lib)
LD_LIBRARYN32_PATH: new-format 32-bit shared library path (/lib32:/usr/lib32)
LD_LIBRARY64_PATH:  64-bit shared library path (/lib64:/usr/lib64)
 
At runtime, the dynamic linker decides which format libraries are required
and uses the appropriate library path environment variable to search for the
needed libraries.
 
The old 32-bit format is identical to the format used on IRIX 5.X.  The
Daylight toolkit libraries in the $DY_ROOT/lib directory are compiled under
the old format (using the -32 option for cc and f77).
 
The new 32-bit format libraries are supported only on IRIX6.X.  The Daylight
toolkit libraries in the $DY_ROOT/lib32 directory are compiled under the new
format (using the -n32 option for cc and f77).

Under IRIX6.X, Daylight now supports 64-bit native toolkit code.  The 64-bit
toolkit libraries are available in the directory $DY_ROOT/lib64.

Unfortunately, XView is not available in either the new 32-bit format or in
64-bit format in this release.  If you are developing XView programs using the
Daylight widgets, they must be compiled using the old format libraries.

Our recommendations for this release are to use the old-format libraries for
all development unless an external factor dictates otherwise.  For example, if
you are developing an application under IRIX 6.X and are linking a set of
third-party libraries which are only available in the new 32-bit format, or
if you require address space sizes greater than 2 Gbytes, you should use the
64-bit toolkits.
 
The default for all Daylight makefiles is to use the old-format 32-bit
libraries.  If you choose to develop using the new-format 32-bit libraries,
you must use the compiler flag -n32, change the library paths to
the new-format versions (/usr/lib32 and $DY_ROOT/lib32) and set the
environment variable LD_LIBRARYN32_PATH for the dynamic linker.
 
See the man page for 'cc' under IRIX 6.X for further discussion of the
differences between the new- and old-format 32-bit libraries.

---------------------------------------------------------------------------

IV.  KERNEL RECONFIGURATION FOR DATABASE SERVERS -- IRIX 5.X

The Problem:

   If you have a very large database, such as the SPRESI database, your
   kernel may be configured with a memory limit that is too small.

   When you try to load the database into the Merlin server, the server
   will report "Out of memory," even when there is plenty of memory.

The Solution:

   Use the "systune" program to reconfigure your system.  The following
   example illustrates raising the memory limits for each process to 1
   gigabyte (only the super-user can do this):

      # systune -i
      systune-> resource

      group: resource (statically changeable)
             rlimit_rss_max = 536870912 (0x20000000)
             rlimit_rss_cur = 1054482432 (0x3eda2000)
             rlimit_vmem_max = 536870912 (0x20000000)
             rlimit_vmem_cur = 536870912 (0x20000000)
             rlimit_nofile_max = 2500 (0x9c4)
             rlimit_nofile_cur = 200 (0xc8)
             rlimit_core_max = 2147483647 (0x7fffffff)
             rlimit_core_cur = 2147483647 (0x7fffffff)
             rlimit_stack_max = 536870912 (0x20000000)
             rlimit_stack_cur = 67108864 (0x4000000)
             rlimit_data_max = 1073741824 (0x40000000)
             rlimit_data_cur = 1073741824 (0x40000000)
             rlimit_fsize_max = 2147483647 (0x7fffffff)
             rlimit_fsize_cur = 2147483647 (0x7fffffff)
             rlimit_cpu_max = 2147483647 (0x7fffffff)
             rlimit_cpu_cur = 2147483647 (0x7fffffff)

      systune-> rlimit_data_max 0x40000000
                rlimit_data_max =  536870912 (0x20000000)
                Do you really want to change rlimit_data_max to 1073741824
                (0x40000000)? (y/n)  y

   In order for the change in parameter rlimit_data_cur to become
   effective, reboot the system.

   Do the same for:

      systune-> rlimit_data_max 0x40000000      (shown above)
      systune-> rlimit_data_cur 0x40000000
      systune-> rlimit_vmem_cur 0x40000000
      systune-> rlimit_vmem_max 0x40000000
      systune-> rlimit_rss_cur  0x40000000
      systune-> rlimit_rss_max  0x40000000

One customer trying to use more than 1 GB reports that several other
parameters had to be changed:

	rsshogfrac to 98
	gpgshi -- still experimenting?
	gpgslo -- still experimenting?

See the system administration manual for complete details, and consult with
your SGI representative for more assistance.


---------------------------------------------------------------------------

V.    KERNEL RECONFIGURATION FOR System V IPC  -- IRIX 5.X

Problem:

Beginning with Version 4.41, the nearneighbors program and the daytoolserver
program use System V semaphores for scheduling and process management.  In
some environments, the default numbers of semaphore configured into the
kernel may be too small.  This is indicated by problems starting either of
the above applications.

Solution:

Reconfigure the kernel with more semaphores.  This is accomplished by performing
the following steps:

1.  Run 'systune -i' as root.  Within this shell, enter the following two
commands:

semmns 256
semmsl 128

2.  Exit the systune shell.

3.  Reboot.

This procedure should increase the number of semaphores sufficiently for 
almost all installations.

---------------------------------------------------------------------------

VI.  KERNEL RECONFIGURATION FOR 64-bit Merlinserver ON IRIX 6.X
WITH 64-BIT KERNEL

The Problem:
 
   If you have a very large database, such as the SPRESI database, your
   kernel may be configured with a memory limit that is too small.
   The 64-bit merlinserver enables loading of multiple large databases
   provided the process limits and combined RAM and swap allow so.

   When you try to load the database into the Merlin server, the server
   will report "Out of memory," even when there is plenty of memory.
 
The Solution:
 
   Use the "systune" program to reconfigure your system.  The following
   example illustrates raising the memory limits for each process to be
   unlimited i.e. limited only by the combined RAM + swap space which should
   exceed the combined size of the databases to be loaded. 
   (only the super-user can do this):
 
      # systune -i
      systune-> resource
 
      group: resource (statically changeable)
             rlimit_rss_max = 536870912 (0x20000000)
             rlimit_rss_cur = 1054482432 (0x3eda2000)
             rlimit_vmem_max = 536870912 (0x20000000)
             rlimit_vmem_cur = 536870912 (0x20000000)
             rlimit_nofile_max = 2500 (0x9c4)
             rlimit_nofile_cur = 200 (0xc8)
             rlimit_core_max = 2147483647 (0x7fffffff)
             rlimit_core_cur = 2147483647 (0x7fffffff)
             rlimit_stack_max = 536870912 (0x20000000)
             rlimit_stack_cur = 67108864 (0x4000000)
             rlimit_data_max = 1073741824 (0x40000000)
             rlimit_data_cur = 1073741824 (0x40000000)
             rlimit_fsize_max = 2147483647 (0x7fffffff)
             rlimit_fsize_cur = 2147483647 (0x7fffffff)
             rlimit_cpu_max = 2147483647 (0x7fffffff)
             rlimit_cpu_cur = 2147483647 (0x7fffffff)
 
      systune-> rlimit_data_max 0x7fffffffffffffff
                rlimit_data_max =  536870912 (0x20000000)
                Do you really want to change rlimit_data_max to 9223372036854775807
                (0x7fffffffffffffff)? (y/n)  y
 
   In order for the change in parameter rlimit_data_cur to become
   effective, reboot the system.
 
   Do the same for:
 
      systune-> rlimit_data_max 0x7fffffffffffffff      (shown above)
      systune-> rlimit_data_cur 0x7fffffffffffffff
      systune-> rlimit_vmem_cur 0x7fffffffffffffff
      systune-> rlimit_vmem_max 0x7fffffffffffffff
      systune-> rlimit_rss_cur  0x7fffffffffffffff
      systune-> rlimit_rss_max  0x7fffffffffffffff

    To obtain the currently available swap space
	# swap -l

    which outputs something similar to
	lswap path         dev    pri swaplo   blocks     free  maxswap    vswap
    2 /usr3/swap/swap1
                   0,315    2      0  8388608  3564512  8388608        0
    1 /dev/swap
                   0,263    0      0  1048576     4128  1048576        0

 
    The swap space is normally mentioned in blocks, each block corresponding to 
    approximately 0.5K. The combined RAM + swap must be at least as large as
    the combined sizes of the databases to be loaded in the pool.

    The available RAM on a system can be obtained by running the command

	#hinv
	
    which outputs something like

	6 195 MHZ IP27 Processors
	CPU: MIPS R10000 Processor Chip Revision: 2.6
	FPU: MIPS R10010 Floating Point Chip Revision: 0.0
	Main memory size: 1024 Mbytes
	Instruction cache size: 32 Kbytes
	Data cache size: 32 Kbytes
	...

    The Main memory size refers to the available RAM on the system (in this 
	case ~1GB)

    To increase the swap space several alternatives are available and are 
    detailed on the system documentation (accessible with the command "insight"
    or with "man swap")

---------------------------------------------------------------------------

VII. SHARED OBJECTS and RUNTIME DYNAMIC LINKING

With version 4.61, Daylight has converted all of its executables to use
dynamic runtime linking.  This feature allows the operating system to
more efficiently use its resources when multiple users are executing
Daylight programs.  The operating system only needs to load one copy of
the Daylight libraries into memory to service all program users.  This saves
memory, and can significantly improve overall system throughput for a
heavily loaded system.

A secondary benefit of this change is that the binaries of Daylight programs
are smaller by a factor of 5 - 10X.  Basically, this is due to the fact
that the core toolkit code is not duplicated in every binary.

There are two issues related to making this switch to dynamic shared
objects.  First, there is a slight startup penalty while the operating system
figures out where the dynamic shared libraries are found.  This delay is
on the order of 10 milliseconds and should not be noticed by interactive
users.  Furthermore, the overall performance of applications appears to be
better, because the system doesn't have to load a copy of the toolkit for
every application.

The second issue is the requirement that an additional environment variable
be set by every Daylight user.  The environment varible LD_LIBRARY_PATH
is used by the operating system as a search path to find dynamic shared
objects under IRIX5.  If the needed shared objects are not found, then a
program will not execute.  The default library search path is typically set
to: /usr/lib:/lib/

The directory $DY_ROOT/lib/ must be added to this path.

sh and ksh:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DY_ROOT/lib/
export LD_LIBRARY_PATH

csh:

setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${DY_ROOT}/lib/

Once set, Daylight executable programs will run without further intervention.
If this variable is set incorrectly, Daylight programs will fail with the
following messages:

$ thorls
29525:thorls: rld: Fatal Error: cannot map soname 'libdt_thor.so' using any
of the filenames /usr/lib/libdt_thor.so:/lib/libdt_thor.so: -- either the
file does not exist or the file is not mappable (with reason indicated in
previous msg)

This message indicates that the runtime linker can't figure out where
the file 'libdt_thor.so' is located.  Correctly setting the LD_LIBRARY_PATH
will fix this problem.

NOTE:  The program testlicense is not dynamically linked, since the license
management code must be present in every executable.  Testlicense
will run successfully even though the LD_LIBRARY_PATH variable is not set.

For IRIX6, the situation is slightly complicated by the fact that SGI
supports three separate binary formats.  Daylight provides all three
binary formats of the Dynamic Shared libraries.  Each user must set three
different environment variables as follows:

sh and ksh:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$DY_ROOT/lib
LD_LIBRARYN32_PATH=$LD_LIBRARYN32_PATH:$DY_ROOT/lib32
LD_LIBRARY64_PATH=$LD_LIBRARY64_PATH:$DY_ROOT/lib64

export LD_LIBRARY_PATH LD_LIBRARYN32_PATH LD_LIBRARY64_PATH

csh:

setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${DY_ROOT}/lib/
setenv LD_LIBRARYN32_PATH ${LD_LIBRARYN32_PATH}:${DY_ROOT}/lib32/
setenv LD_LIBRARY64_PATH ${LD_LIBRARY64_PATH}:${DY_ROOT}/lib64/

Once these three environment variables are set, the system will
automagically use the correct libraries for a given binary.

In version 4.61 and 4.62, both dynamic and static libraries are included in
the Daylight distribution (".so" and ".a" files).  In a future release, we
will drop the static libraries and only ship the dynamic libraries.

---------------------------------------------------------------------------