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
