4.81 Release Notes for SGI IRIX Computers

Back to 4.81 Release Notes.

CONTENTS

    I.    FEATURES THAT AFFECT SGI USERS
    II.   OBJECT-CODE FORMATS
    III.  KERNEL RECONFIGURATION FOR DATABASE SERVERS
    IV.   KERNEL RECONFIGURATION FOR System V IPC
    V.    KERNEL RECONFIGURATION FOR 64-bit Merlinserver
    VI.   SHARED OBJECTS and RUNTIME DYNAMIC LINKING
    VII.  THORSERVER & MERLINSERVER

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

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

These 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. OBJECT-CODE FORMATS

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

Several years ago, in order to support 64-bit native systems, SGI 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:    default 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.  LD_LIBRARY_PATH is searched first for libraries which match
the required format.  Hence, the typical Daylight installation only requires
that LD_LIBRARY_PATH includes $DY_ROOT/lib.  Furthermore, it is legal to 
include different format library paths in LD_LIBRARY_PATH, and omit the
definition of LD_LIBRARYN32_PATH or LD_LIBRARY64_PATH.
 
For this version, Daylight is using -n32 as the default format for all
compilations and executables.  We are using slightly different 
naming conventions for our libraries.

The old 32-bit format libararies are no longer supported and are not shipped
with this release.
 
The new 32-bit format libraries are in the $DY_ROOT/lib directory.
They are compliled using the -n32 option for cc and f77, which are now 
default on the SGI C-compiler. (See previous paragraph)

Under IRIX6.X, Daylight 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 64-bit format in this release.
If you are developing XView programs using the Daylight widgets, they must 
be compiled using the new format 32-bit libraries.  In this case, at runtime, 
LD_LIBRARY_PATH must include $DY_ROOT/lib in order for the runtime linker 
to find the appropriate files.

To compile the contrib code in new 32-bit format in $DY_ROOT/contrib/src
type "make". To compile the contrib code in 64-bit format 
in $DY_ROOT/contrib/src type "make -f makefile_64". To compile the 
individual directories with contrib code (i.e. $DY_ROOT/contrib/src/c/smiles)
in 64-bit the makefile must be altered by changing the line 
include $(CONTRIB)/src/makefile_include to 
include $(CONTRIB)/src/makefile_include_64.
  
---------------------------------------------------------------------------

III. KERNEL RECONFIGURATION FOR DATABASE SERVERS

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 =  536870912 (0x20000000)
             rlimit_data_cur =  536870912 (0x20000000)
             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.


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

IV.  KERNEL RECONFIGURATION FOR System V IPC

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.

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

V.   KERNEL RECONFIGURATION FOR 64-bit Merlinserver

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.

   In practice it has been found that 32-bit Merlinserver can't have a pool
   size greater than 1.7 GB on IRIX. For any pool size above this, we
   recommend using 64-bit Merlinserver
 
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
   swap 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")

   After doing this if you're using the C-Shell or a derivative such as tcsh,
   make sure that your user limits are all set to be unlimited or are set to
   the hard limits set by the OS. To check your limits run:

   csh% limit   
   cputime         unlimited
   filesize        unlimited
   datasize        unlimited
   stacksize       65536 kbytes
   coredumpsize    unlimited
   memoryuse       2097152 kbytes
   descriptors     1024 
   vmemoryuse      unlimited

   To unlimit any parameter that is limited (e.g. memoryuse) run the command:

   csh% limit memoryuse unlimit

   If the limit command still shows a limit for memoryuse, this is a parameter
   that is hard set in your kernel. If the limit is not sufficient (i.e., it
   is < 4GB (2^32)) see the top part of this section for information on
   how to increase this limit if needed.

   csh% limit datasize unlimit

   The datasize limit controls the maximum size of the data segment.
   This limit should either be set to unlimited or to a value larger than the
   expected merlinserver size.

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

VI. 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.  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 supports n32 and 64 
binary formats of the Dynamic Shared libraries.  We recommend setting the
different environment variables as follows:

sh and ksh:

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

export LD_LIBRARY_PATH LD_LIBRARY64_PATH

csh:

setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${DY_ROOT}/lib/
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.

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

VII. THORSERVER & MERLINSERVER

The thorserver uses 34-bit file offsets and has a database file size limit
of 16GB.  Writing data beyond the limit will cause database corruption.
As a protective measure, the thorserver will deny I/O and issue a
nonfatal error when a load of a TDT begins within 1MB of the limit.
If you want to load large (>1MB) TDT's, you are unprotected from
writing beyond the limit.

Back to 4.81 Release Notes.