gcc on Linux is brain-dead w.r.t. run-time link paths. In order
to add any run-time search dir, you must specify "-Wl,-rpath <path>"
to add a dir via gcc. However, libtool only recognizes "-R" or
"-rpath" as the link path options. So, these two options are
completely incompatible. (FWIW, gcc on Solaris recognizes -R
natively, so it isn't a problem there - -R works for both gcc
and libtool - probably why I've skirted the issue for so long.)
I usually add the Berkeley DB libraries so APR-util finds it
(SVN requires that apr-util links against db-4.0.14 which is
different than what is in my /usr/lib):
CPPFLAGS="-I/pkg/db-4.0.14/include" \
LDFLAGS="-L/pkg/db-4.0.14/lib -Wl,-rpath /pkg/db-4.0.14/lib" \
./configure ...<options>...
If we specify "-Wl,-rpath", we fail at link-time when building
the binaries, since libtool does not understand -Wl,-rpath.
However, if you specify "-R" instead of -Wl,-rpath, we will fail
at configure-time in httpd since configure will try to link with
LDFLAGS and gcc will say that "-R" is unrecognized.
This is a complete Catch-22. The question is what to do about it.
I have some ideas, but I'd like to hear what other people think.
I won't prejudice you all with my proposed solutions because I
think they are all a bit unelegant. (I'm also curious if we end
up with what I already have.) It looks technically feasible,
but my solutions turn into a complete mess. Hint: we can't just
handle this in httpd as we must build all of the subprojects (apr,
apr-util, pcre) with the proper conversion. It just sucks. But,
my builds are completely broken on Linux with -rpath LDFLAGS. So,
we need some sort of solution. (IMHO, ldconfig isn't a solution
since it requires root access.) -- justin
|