4.61 Release Notes for Sun Solaris 2.x Computers

Back to 4.61 Release Notes.
Rev: Jul 15, 1998

CONTENTS
   I.  KERNEL RECONFIGURATION FOR System V IPC -- Solaris 2.X
   II. SHARED OBJECTS and RUNTIME DYNAMIC LINKING
 
--------------------------------------------------------------------------

I. KERNEL RECONFIGURATION FOR System V IPC  -- Solaris 2.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 (you must be root):

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

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.

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

II. 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:/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.

In version 4.61, 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.

---------------------------------------------------------------------------
Back to 4.61 Release Notes.