Tru64 and rpath

Scott Adkins adkinss at
Wed Aug 25 14:53:23 EDT 2004

We are about to upgrade our production system to 2.2.8.  One of the biggest
problems that I am fighting is the rpath issue.  Basically, it is important
for the binaries (imapd, pop3d, etc) to be able to find both the SSL libs
and the SASL2 libs.  When I configure the server, I set LDFLAGS to set the
appropriate rpath options so that when I do compile the server, it will
include the library paths in the binaries.

Basically, it looks like this:

  export CC="cc"
  export LDFLAGS="-Wl,-rpath,$SSLDIR/lib:$SNMPDIR/lib:$SASLDIR/lib"

  ./configure --with-sasl=SASLDIR --with-openssl=$SSLDIR ......

What is the problem?  The problem is that it doesn't work.  The compiler
on Tru64 (cc), does not handle multiple rpath options on the command line
in the same way that gcc does.  In fact, Tru64 expects only one rpath
option on the command line, and if there are multiple rpath's specified,
only the last one on the command line will be accepted.

The proper way to handle this in Tru64 is to make the path colon delimited
(as in the above LDFLAGS setting) and make sure that it appears as the only
one on the command line, or that it appears last on the command line.

This is now how it works with Cyrus... the configure process builds the
rpath stuff as it is configuring it.  Since I set the LDFLAGS stuff before
configuration, the configure script puts it first on the command line.  As
it builds the libraries that it must include (using the -L and -l stuff),
it adds to the command line and adds additional rpath options as well,
which override the previous ones.   The end result is that my binaries
are dumb with how to find all but one of the shared libraries.

The only solution that I have right now is to hack all the Makefile's after
the configuration process has completed to remove the extra rpaths.  That
is quite painful.  The other thing I could do is hack the startup scripts
to set LD_LIBRARY_PATH, and hack the perl scripts to do the same and make
sure that anything we write that interfaces with Cyrus does the same too.

Personally, I would rather see it solved at configuration time, but I have
yet to figure out a way to do so.

Any ideas?

There doesn't seem to be a way to force configure to either create an
appended form of a single rpath, or to not build rpath information at all.
Either method would work for me.

      Scott W. Adkins      
   UNIX Systems Engineer                  mailto:adkinss at
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
     PGP Public Key available at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 231 bytes
Desc: not available
Url :

More information about the Info-cyrus mailing list