Yes, the libraries all work fine when used as either static or shared. If you look at the APR ABI rules you will see that you can install the newer 1.3 versions overtop of the 1.2 version without worrying about API incompatibilities, only when they move to a v2 are they allowed to make revisions to the older API functions. I've installed the latest over my CentOS installed APR without issue.
Regards Tim. On Fri, 2008-12-05 at 11:39 -0800, Jim Lloyd wrote: > To answer my own questions: > All three components (apr, apr-util, and activemq-cpp) seem to build fine > when configured with --disable-shared. I'm able to build and run my test > apps against the static libraries. > > On Thu, Dec 4, 2008 at 8:22 PM, Jim Lloyd <[EMAIL PROTECTED]>wrote: > > > I think there is a possibility that my problem with my activemq-cpp 2.2.2 > > consumer locking up is because I messed up with installing apr-1.3.3 and > > apr-util-1.3.4 on my CentOS 5.2 system. > > > > A previous version of APR is installed via yum, and too many packages rely > > on it in order for me to consider removing it. I tried to install the new > > packages in separate directories, but I realize now I specified only > > --prefix and not --exec-prefix when I ran ./configure. > > > > I'm going to try to unwind and fix this. But I wonder if anyone else has > > good strategies for leaving APR where it is installed by default in CentOS > > while having a new version installed in a non-standard place. > > > > Has anyone built apr, apr-util, and activemq-cpp all with static libraries > > only, to eliminate any problems with shared library conflicts? > > > > I should mention that I discovered a shared library conflict when I made a > > relatively simple change to my modified SimpleAsyncConsumer. I added the use > > of some apr_time routines, and then discovered the program would not launch > > due to unresolved references in the shared libraries. Adding a directory to > > my LD_LIBRARY_PATH allowed the program to run, and it seemed to be running > > better than I had seen it so far. > > > > Thanks, > > Jim Lloyd > > > > > > -- Tim Bish http://fusesource.com http://timbish.blogspot.com/
