Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 2 Nov 2000 11:28:22 -0800 (PST)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0/src/lib/apr/include apr.hw
In-Reply-To: <20001102101521.B2037@lyra.org>
Message-ID: <Pine.LNX.4.21.0011021124060.24485-100000@koj.covalent.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> Sure.
> 
> I compile Subversion against a UTF-8 version of APR because we transport
> filenames via XML, thus we UTF-8 encode the filenames. I ship my binaries.
> 
> I compile Apache against a native-encoding version of APR because all the
> config files use native encoding. I ship my binaries.
> 
> Somebody ships an RPM of APR and that is installed on my machine. It was
> just a library (the header comes with the "libapr-devel" package).
> 
> Okay... now answer this: which app breaks? Subversion or Apache? How was APR
> compiled?

Neither.   Apache uses a statically compiled version of APR.  If
Subversion was smart, it would too.  This is a standard problem with
shared libraries, and that is one of the reasons that Apache is statically
linking APR.  We have never figured out the "correct" way to deal with
shared libraries with APR.  Think of it this way.

I have two APR programs, one is threaded, one isn't.   If I compile APR to
have threads, then I hurt the performance in the non-threaded program.  If
I compile APR non-threaded, then I break the threaded one.

The only sane solution with a library with as many options as APR has is
to compile most programs static.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------