4.92 Release Notes for Sun Solaris 2.X Computers

Back to Release Notes.



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.


   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.



   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:


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

   sh and ksh:

     export LD_LIBRARY_PATH



   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

   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/lib32 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".



   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.