=============================== CONTENTS =================================


   I.   KERNEL RECONFIGURATION FOR System V IPC -- Solaris 2.X
   II.  SHARED OBJECTS and RUNTIME DYNAMIC LINKING
   III. THORSERVER & MERLINSERVER
 





====== 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.

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 new  format 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". 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. 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.