Tru64 and rpath

2004-08-25 Thread Scott Adkins
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.
Thanks,
Scott
--
+---+
 Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/
  UNIX Systems Engineer  mailto:[EMAIL PROTECTED]
   ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+---+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/

pgpbSt2SwLX46.pgp
Description: PGP signature


Re: Tru64 and rpath

2004-08-25 Thread Derrick J Brashear
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.
RPATH should be being set in configure; there's a hardcoded list of how it 
works for each systype and then RPATH gets AC_SUBST'd. tru64 isn't in one 
of the cases. add a case for tru64 and make the rpath components get 
appended.

all of the source for the configure tests should be in the cmulocal 
directory.

---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html