On 18/10/09 19:57, Jeff Trawick wrote:
There is no consensus yet on the scope of what has to be addressed
(distinct from whether the project or the packager should address it).
The discussion in the earlier commit thread needs to be carried to
its conclusion.
What about simply making
Joe Orton wrote:
Sorry I haven't sent out this review sooner.
Sorry I didn't volunteer to release APR v1.4 sooner ;)
Broader issues:
** Having both apr_crypto_init() and apr_crypto_get_driver() seems to be
redundant (unnecessary complexity in API and code). The lowest common
On Mon, Oct 19, 2009 at 2:53 AM, Mladen Turk mt...@apache.org wrote:
On 18/10/09 19:57, Jeff Trawick wrote:
There is no consensus yet on the scope of what has to be addressed
(distinct from whether the project or the packager should address it).
The discussion in the earlier commit thread
On 19/10/09 13:28, Jeff Trawick wrote:
What about simply making apr.h/apu.h as a stubs
for apr-$CPU.h
(I don't yet see how we can make a useful contribution on other
aspects of multi-architecture support -- fat binary or multiple
bin/lib/build directories or )
The bottom line is
On 19/10/09 14:43, Jeff Trawick wrote:
Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 ./configure
is a little bit awkward and nowhere documented)
BTW, you have to specify the arch option in CC for all the
apr-n-config stuff to work
On Mon, Oct 19, 2009 at 9:17 AM, Mladen Turk mt...@apache.org wrote:
On 19/10/09 14:43, Jeff Trawick wrote:
Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 ./configure
is a little bit awkward and nowhere documented)
BTW, you have to
On 19/10/09 15:41, Jeff Trawick wrote:
Perhaps I'm out in left field, but I anticipate that packagers will
determine the appropriate arch flags based on exactly what hardware
they support, and use that across a number of open source packages.
Sure.
(Should foo-32 support any 32-bit foo
Mladen Turk wrote:
Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 ./configure
is a little bit awkward and nowhere documented)
Resolving that would certainly be one small step helping
packagers to solve some of the multi-arch
On 19/10/09 16:37, William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Anyhow, APR currently lacks the configure options for at
least specifying data model (using CFLAGS=-m32 ./configure
is a little bit awkward and nowhere documented)
Resolving that would certainly be one small step helping
On 18 Oct 2009, at 18:14, Jim Jagielski wrote:
On Oct 18, 2009, at 1:00 PM, Jeff Trawick wrote:
I don't think anybody has spelled out explicitly how to run the apr
and apr-util builds and merge all necessary headers and so forth (not
that it is complicated, but it would be useful as a
Barry Scott wrote:
I think the problem is that configure is used to find out things that
change arch to arch
like void * size rather then using preprocessor detection of those things.
I wonder, how do you detect the size of void* with the preprocessor in
C? The preprocessor doesn't understand
11 matches
Mail list logo
