4.92 Release Notes for Linux

Back to Release Notes.


    2. 64-BIT SUPPORT



   The 4.92 Linux release for Daylight software needs the following:

    o) An Intel x86 (or compatible) or AMD Opteron-based
       machine running Linux, with networking.

    o) RedHat Linux Enterprise Editions (2.1, 3, 4) on x86,
       RedHat Linux Enterprise Edition 3.0 on AMD64.

    o) A networked ethernet card on the PC.  This is essential,
       as the card's MAC address is used for licensing.



   Beginning with release 4.91, the Linux distribution contains
   64-bit objects for Opteron (AMD64).  The Linux release contains 
   two sets of lib and bin directories, as follows:

     $DY_ROOT/bin      -  32-bit x86 Linux binaries
     $DY_ROOT/lib      -  32-bit x86 Linux libraries

     $DY_ROOT/binAMD64 -  64-bit x86_64 Linux binaries
     $DY_ROOT/libAMD64 -  64-bit x86_64 Linux libraries

   For a regular 32-bit x86-based Linux system the 64-bit
   directories can be ignored.  They are not needed.

   For 64-bit Opteron, both the 32-bit and 64-bit
   objects may be needed, depending on the users application.

   Currently, the only 64-bit application provided is
   merlinserver, which can take advantage of the large memory
   addressing of 64-bits.  The 64-bit libraries for all supported
   toolkits are available for developers.

   One installation/configuration note:  It is recommended that
   users of 64-bit Linux create symbolic links for bin64 and
   lib64.  In general the Daylight documentation refers to these
   directories.  Furthermore, code and makefiles in contrib and
   the thorhome configuration refer to these directories.

     cd $DY_ROOT
     ln -s binAMD64 bin64
     ln -s libAMD64 lib64

   NOTE: This organization allows us to add IA64 support
   at a future date, with binIA64 and libIA64 directories,
   without a reorganization of the directories.

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



   There are a set of XView-based graphical programs included in the 
   Daylight 4.92 distribution. To run these, XView needs to be installed
   on the client. The XView RPMs are not installed by default but can
   either be installed as optional packages from Red Hat or copied
   from the distribution.

   To install the package from the RPM included in the release, 
   become root on your Linux machine, and then type:

     cd $DY_ROOT/exotic/XView/linux
     rpm -U xview*rpm

   Furthermore, to use the 'Print Preview' option in the XV applications,
   one must install the 'gv' package.  The 'gv' package is included on
   the Linux RedHat distribution.



   Intel and Intel-compatible processors, unlike the SGI MIPS or 
   Sun SPARC processors, are little endian. Endianness refers to how
   the byte-ordering which the processor uses internally to store
   numbers. A big endian processor like the Sun SPARC or SGI MIPS
   processor represents a number 0x1000, as 0x1000 internally.
   A little endian processor like the Intel Pentium represents this
   as 0x0001 internally instead.  The ordering of the individual bytes
   is swapped.  This is a factor when performing datatype conversion
   and writing binary files.

   The Daylight software has been written so that endianness is never an
   issue. Hence all Daylight Database files may be used interchangeably
   between Sun, SGI or Intel-Linux computers. The only case where endianness
   is an issue is in the clogp binary database files. You cannot use a
   fragment database binary file created on a Sun or SGI on an Intel Linux
   computer. However the textual form of the fragment files can be
   interchanged and used. When the clogp program runs the first time, it
   checks for a binary file and generates it, if not present, from the text
   file. The generated binary file is of the correct endianness for
   the system.



   Prior to version 4.91, thorserver used 32-bit file offsets and had 
   a database file size limit of 2GB.  Beginning with 4.91 all 
   Thor databases can be created up to the 16GB datafile limit.
   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.



    The following information addresses a linking issue which arises
    on later Red Hat versions in the following situations:

    - Running ES3.0 (or later, presumably)
    - Statically linking a Daylight toolkit program 

    One will get errors from the link step:

      undefined reference to '__ctype_b'
      undefined reference to '__ctype_tolower'
      undefined reference to '__ctype_toupper'

    Red Hat only guarantees forwards binary compatibility for
    executables and shared object libraries; not for object
    files or archives.  The Daylight toolkit archives are
    built using Red Hat ES 2.1.  Red Hat removed the symbols
    __ctype_b, __ctype_lower and  __ctype_upper from glibc
    beginning with version 2.3. 

    The three symbols were removed in favor of locale-aware
    versions, and the older versions are no longer be
    available.  Red Hat has indicated that they don't consider
    this a bug and have no plans to change the behavior.

    There are two simple workarounds:

    First, link dynamically rather than statically.  So, in the
    makefile or link statement, change the references to all
    of the Daylight libraries as follows:


    gcc -o myprogram.exe myprogram.o ... libdt_smiles.a

    Dynamic (preferred):

    gcc -o myprogram.exe myprogram.o ... -L $(DY_ROOT)/lib -ldt_smiles

    The second workaround comes from the Red Hat bugs database
    and is provided here unmodified for convenience.   See
    for the complete listing of the fix:

    Customer Fix
    We used a brute force approach. Make the following code into
    a .c file, and include it in your program. At the start of 
    main(), call ctSetup().

    Make sure you compile statically or else the dynamic loader will 
    cause problems.

    I've seen others use macros, but this worked good enough for us... 

    #include <ctype.h>

    __const unsigned short int *__ctype_b;
    __const __int32_t *__ctype_tolower;
    __const __int32_t *__ctype_toupper;

    void ctSetup()
    __ctype_b = *(__ctype_b_loc());
    __ctype_toupper = *(__ctype_toupper_loc());
    __ctype_tolower = *(__ctype_tolower_loc());

    Also, additional information is available in the bugs
    database at redhat.com.   A search for the string "__ctype_b" 
    at http://bugzilla.redhat.com/bugzilla/ is the simplest
    way to get the latest information.  As of Jan, 28, 2004,
    the following entries were found:


Back to Release Notes.