4.94 Release Notes for Sun Solaris Computers

Back to Release Notes.

CONTENTS

   1. SUPPORTED ARCHITECTURES
   2. KERNEL RECONFIGURATION
   3. SHARED OBJECTS and RUNTIME DYNAMIC LINKING
   4. THORSERVER & MERLINSERVER
 
----------------------------------------------------------------------------

   1. SUPPORTED ARCHITECTURES

   Begining with version 4.93, there are two Daylight distributions
   available for Solaris, the SPARC version and the x86 version.

   The SPARC/Solaris distribution is supported on Solaris 7 and
   higher and includes 32-bit (SPARC v7) and 64-bit (SPARC v9)
   libraries and binaries.

   The x86/Solaris distribution is supported on Solaris 10 and higher
   and includes 32-bit (x86) and 64-bit (x86_64) libraries and
   binaries.

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

   2. KERNEL RECONFIGURATION

   The Problem:

   Beginning with Version 4.41, the nearneighbors program uses System V
   semaphores for scheduling and process management.  In some
   environments, the default number of semaphores 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 (you must be root):

   1.  Edit the file /etc/system.  Add the following two lines:

     set semsys:seminfo_semmns=256
     set semsys:seminfo_semmsl=128

   2.  Save the file.

   3.  Reboot.

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

   See the Solaris System Administration manual for more details.

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

   3. 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 variable
   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:/usr/openwin/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
    ld.so.1: thorls: fatal: libdt_thor.so: can't open file: errno=2
    Killed

   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.

   Daylight now supports 32-bit code as well as 64-bit code. Daylight
   is using 32-bit as the default format.  The 64-bit toolkit libraries
   are available in the directory $DY_ROOT/lib64.  The binaries are
   available in the directory $DY_ROOT/bin64.

   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 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 32-bit format, in $DY_ROOT/contrib/src
   type "make install". To compile the contrib code in 64-bit format,
   in $DY_ROOT/contrib/src type "make install64".

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

   4. 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 Release Notes.