Tru64 and 2.2 problems

[Scott Adkins]

Okay, I have enough problems now to post something.

We are running on a Tru64 5.1a cluster (2 machines).  Compiling 2.2.1 has
not been a pleasant prospect.  We are using Tru64's cc compiler, and are
not permitted to use the gcc compiler.

First thing is first, we are using SASL-2.15.1 and BerkeleyDB 4.0.14.  The
configure process is ran with the following code in a script:

  SSL=/usr/local/ssl
  SASL=/usr/local/sasl-2.1.15
  BERK=/usr/local/BerkeleyDB.4.0
  SNMP=/usr/local/net-snmp-4.2.1

  CFLAGS="-I$SSL/include -I$SASL/include -I$BERK/include -I$SNMP/include 
-gall"
  RPATH="-Wl,-rpath,$SSL/lib:$SASL/lib:$BERK/lib:$SNMP/lib"
  LDFLAGS="-L$SSL/lib -L$SASL/lib -L$BERK/lib -L$SNMP/lib $RPATH"
  export CFLAGS LDFLAGS

  ./configure --with-sasl=/usr/local/sasl-2.1.15 \
              --with-dbdir=/usr/local/BerkeleyDB.4.0 \
              --with-ucdsnmp=/usr/local/net-snmp-4.2.1 \
              --with-openssl=/usr/local/ssl \
              --with-egd-socket=/var/run/egd-pool \
              --with-pidfile --enable-listext \
  2>&1 | tee configure.output

With respect to the compile errors, this is what I have found:

 1) The configure process appears to pick up on the fact that Tru64 does
    have getnameinfo(), but not getaddrinfo().  The problem is that if one
    is found and the other is not, the definitions for both are included
    in lib/gai.h.  Well, getnameinfo() on Tru64 has a slightly different
    definition and produces a conflict that the compiler can't resolve.
    The solution was to modify gai.h and wrap the getaddrinfo() related
    routines with "#ifndef HAVE_GETADDRINFO/#endif" macros, and wrap the
    getnameinfo() with similar HAVE_GETNAMEINFO macros.

 2) So, I get past the above, and run right smack into another problem,
    this time with lib/imapopts.c.  I get over a 100 lines of errors along
    the lines of the following:

    {IMAPOPT_ADMINS,"admins",0,(union config_value)((const char 
*)""),OPT_STRING},
    ---------------------------^
    {IMAPOPT_ALLOWALLSUBSCRIBE,"allowallsubscribe",0,(union 
config_value)((int)0),OPT_SWITCH},
    -------------------------------------------------^
    {IMAPOPT_ALLOWNEWNEWS,"allownewnews",0,(union 
config_value)((int)0),OPT_SWITCH},
    ---------------------------------------^

    Basically, ever line in that table generates an error on the union
    construct.  I don't understand the error message, been even more so, I
    don't understand why the union is even there at all.  It appears that
    this file is automatically generated by the following command:

      ../tools/config2header imapopts.c imapopts.h < imapoptions

    The config2header script talks about playing an interesting game to get
    the union to initialize itself in a syntacticly valid manner, namely to
    initialize the union itself and not the members of the union, as well as
    to ensure that the union is initialized to something of a type that is
    in that union.  What do I say about that?  Very bizarre, and it doesn't
    work in Tru64.

    Doing a mass delete of all the '(union config_value)' stuff in the file
    gets the code to compile, but I don't know what kind of problems that 
is
    going to cause me if it has to do with initializing things.

    Any thoughts on how to handle this problem?

    I get similar errors when compiling libcyr_cfg.c as well, but in a
    slightly different context, and doing the same deletion gets it to at
    least compile.

 3) After that, it compiles for awhile and then stops on imap/protocol.c
    with the following error:

      cc: Error: ./../lib/prot.h, line 209: Missing ";". (nosemi)
      __attribute__ ((format (printf, 2, 3)));

    Looking in lib/prot.h, I see the following:

      extern int prot_printf(struct protstream *, const char *, ...)
          __attribute__ ((format (printf, 2, 3)));

    What is that supposed to do?  I simply deleted the line that has the
    __attribute__ on it and put a semicolon on the previous line and it
    compiles.  What problems will I see by doing that?

 4) Okay, everything compiled.  However, I saw a lot of these errors when
    linking the final executables:

     Unrecognized argument in LIBS ignored: 
'-Wl,-rpath,/usr/local/BerkeleyDB.4.0/lib'
     Unrecognized argument in LIBS ignored: 
'-Wl,-rpath,/usr/local/sasl-2.1.15/lib'
     Unrecognized argument in LIBS ignored: '-Wl,-rpath,/usr/local/ssl/lib'

    In fact, if I do an 'ldd imap/imapd', I get the following error:

     imap/imapd: ldd: Fatal Error: Cannot generate dynamic dependencies for
       library libsasl2.so

    Of course, the executables won't even run at this point.  I can set the
    LD_LIBRARY_PATH info by hand and get them to work, but that isn't ideal
    and I shouldn't have to with the current technology of using rpath.  I
    don't know how it works in Linux or other systems, but in Tru64, the use
    of multiple rpaths are *not* additive... the last one provided on the
    command line wins... I specified my own in the LDFLAGS variable before
    compiling, but apparently, the configure process added a whole much more
    with rpath doing its own lib directory, and mine got lost in the noise.
    If I modify all the Makefiles by hand and reconstruct the LIBS, 
IMAPLIBS,
    and LDFLAGS lines that are in the files, I can get the executables to
    link properly and the rpath stuff does indeed allow the lib directories
    to be found.

    However, I better not do another reconfigure... I would lose my changes!
    Is there any way to fix that behavior?

Anyways, I hope someboyd out there can throw some ideas out to me... What I
see right now is a server that acts slower than the 2.0.16 version we were
running, and we are having problems with it staying up too.  I am still
troubleshooting those problems.

Scott
-- 
 +-----------------------------------------------------------------------+
      Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
   UNIX Systems Engineer                  mailto:adkinss at ohio.edu
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
 +-----------------------------------------------------------------------+
     PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 231 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20030722/df3aa9eb/attachment.bin