On Mar 8, 2011, at 9:49 AM, Hyrum K. Wright wrote:
On Fri, Dec 17, 2010 at 10:23 AM, Jim Jagielski j...@jagunet.com wrote:
On Dec 17, 2010, at 11:13 AM, William A. Rowe Jr. wrote:
On 12/17/2010 7:32 AM, Graham Leggett wrote:
While amending the apr.h file after the fact is obviously not
On Tue, Mar 8, 2011 at 1:42 PM, Jim Jagielski j...@jagunet.com wrote:
On Mar 8, 2011, at 9:49 AM, Hyrum K. Wright wrote:
On Fri, Dec 17, 2010 at 10:23 AM, Jim Jagielski j...@jagunet.com wrote:
On Dec 17, 2010, at 11:13 AM, William A. Rowe Jr. wrote:
On 12/17/2010 7:32 AM, Graham Leggett
On Thu. 2010-12-16 at 03:35 PM EST, Jim Jagielski j...@jagunet.com wrote:
On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
(int - long - long long). We also do the same when
On Thu. 2010-12-16 at 03:44 PM EST, William A. Rowe Jr. wr...@rowe-clan.net
wrote:
On 12/16/2010 2:35 PM, Jim Jagielski wrote:
On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
On Dec 17, 2010, at 6:58 AM, Dan Poirier wrote:
On Thu. 2010-12-16 at 03:35 PM EST, Jim Jagielski j...@jagunet.com wrote:
On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
(int -
On Dec 16, 2010, at 4:38 PM, William A. Rowe Jr. wrote:
On 12/16/2010 3:36 PM, Jim Jagielski wrote:
+# where int and long are the same size. Use the longest
+# type that fits
+if test $ac_cv_sizeof_off_t = $ac_cv_sizeof_long_long; then
+off_t_fmt='#define APR_OFF_T_FMT
On Dec 17, 2010, at 7:29 AM, Jim Jagielski wrote:
Example: if I build universal (CFLAGS='-arch i386 -arch x86_64'), the compile
fails in strings/apr_snprintf.c:
Hmmm I cannot recreate that (at least on the 1.4.x branch).
What happens if you just blank out CFLAGS? The default
is
On 17 Dec 2010, at 2:33 PM, Jim Jagielski wrote:
Hold on, yeah, it does seem to still not like universal.
But at least this is better than it was...
A while back I asked Apple directly what their solution was, and they
said they amend the apr.h after the fact using this:
On Dec 17, 2010, at 8:32 AM, Graham Leggett wrote:
On 17 Dec 2010, at 2:33 PM, Jim Jagielski wrote:
Hold on, yeah, it does seem to still not like universal.
But at least this is better than it was...
A while back I asked Apple directly what their solution was, and they said
they
On 17 Dec 2010, at 3:53 PM, Jim Jagielski wrote:
iirc, the concept of using __LP64__ was nixed (iirc, about a year
ago I had a large patch set which used that). r824818 and r824762
Not sure if that veto is still valid or not.
As I recall, the veto attempted to veto the concept of an Apple
On Dec 17, 2010, at 9:12 AM, Graham Leggett wrote:
On 17 Dec 2010, at 3:53 PM, Jim Jagielski wrote:
iirc, the concept of using __LP64__ was nixed (iirc, about a year
ago I had a large patch set which used that). r824818 and r824762
Not sure if that veto is still valid or not.
As I
On 12/17/2010 6:31 AM, Jim Jagielski wrote:
Oh, yeah. Well, it's not only the format but
everything as well... After all, if long long is 128bits,
you don't want to use apr_strtoi64 either.
Exactly
I would suggest that we tackle that issue separately?
Sure, of course. Show me broken
On 12/17/2010 7:32 AM, Graham Leggett wrote:
While amending the apr.h file after the fact is obviously not the solution,
picking apart
what they've done and building it into the apr.h.in should work.
Right, Fred had submitted this to the list. Joe had vetoed.
/me Grabs for the popcorn :)
On Dec 15, 2010, at 5:11 PM, Dan Poirier wrote:
On Mon. 2010-11-08 at 10:27 AM EST, Jim Jagielski j...@jagunet.com wrote:
On Nov 7, 2010, at 7:42 PM, Jeff Trawick wrote:
On Sun, Nov 7, 2010 at 6:51 PM, Chris Knight
christopher.d.kni...@nasa.gov wrote:
Exactly, the problem only appears
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
(int - long - long long). We also do the same when
checking apr_int64_t as well...
What if we do the reverse? What if instead of finding
the smallest that is the right size, we find the
On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
(int - long - long long). We also do the same when
checking apr_int64_t as well...
What if we do the reverse? What if instead of
On 12/16/2010 2:35 PM, Jim Jagielski wrote:
On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
(int - long - long long). We also do the same when
checking apr_int64_t as well...
+
On Dec 16, 2010, at 3:44 PM, William A. Rowe Jr. wrote:
On 12/16/2010 2:35 PM, Jim Jagielski wrote:
On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
Here is my idea... currently, when looking for sizes
and formats for off_t, we do from smallest to largest
(int - long - long long). We
On Mon. 2010-11-08 at 10:27 AM EST, Jim Jagielski j...@jagunet.com wrote:
On Nov 7, 2010, at 7:42 PM, Jeff Trawick wrote:
On Sun, Nov 7, 2010 at 6:51 PM, Chris Knight
christopher.d.kni...@nasa.gov wrote:
Exactly, the problem only appears on 64-bit Snow Leopard. See my patch in
Bugzilla,
On Nov 7, 2010, at 7:42 PM, Jeff Trawick wrote:
On Sun, Nov 7, 2010 at 6:51 PM, Chris Knight
christopher.d.kni...@nasa.gov wrote:
Exactly, the problem only appears on 64-bit Snow Leopard. See my patch in
Bugzilla, which I've verified. (Unsure if the below would also work, been a
long time
On 08 Nov 2010, at 5:27 PM, Jim Jagielski wrote:
If one forces *just* 64bit, then, afaict, the patch is not needed.
It's only if one builds APR with both i386 and x86_64 that
things break...
Building with both is default behaviour, and has been default
behaviour since universal binaries
On Nov 4, 2010, at 12:15 PM, William A. Rowe Jr. wrote:
Looks good here.
If folks find this unproblematic, can someone please commit it? I don't have
karma here.
Thanks,
S.
--
san...@temme.net http://www.temme.net/sander/
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0
On Sun, Nov 7, 2010 at 5:07 PM, Sander Temme san...@temme.net wrote:
On Nov 4, 2010, at 12:15 PM, William A. Rowe Jr. wrote:
Looks good here.
If folks find this unproblematic, can someone please commit it? I don't have
karma here.
Thanks,
looks fine to me; starting to try it out now
On Sun, Nov 7, 2010 at 5:18 PM, Jeff Trawick traw...@gmail.com wrote:
On Sun, Nov 7, 2010 at 5:07 PM, Sander Temme san...@temme.net wrote:
On Nov 4, 2010, at 12:15 PM, William A. Rowe Jr. wrote:
Looks good here.
If folks find this unproblematic, can someone please commit it? I don't
have
Exactly, the problem only appears on 64-bit Snow Leopard. See my patch in
Bugzilla, which I've verified. (Unsure if the below would also work, been a
long time since I diagnosed.)
On Nov 7, 2010, at 3:36 PM, Jeff Trawick wrote:
On Sun, Nov 7, 2010 at 5:18 PM, Jeff Trawick traw...@gmail.com
On Sun, Nov 7, 2010 at 6:51 PM, Chris Knight
christopher.d.kni...@nasa.gov wrote:
Exactly, the problem only appears on 64-bit Snow Leopard. See my patch in
Bugzilla, which I've verified. (Unsure if the below would also work, been a
long time since I diagnosed.)
What I understood was that
Folks,
I was seeing test failures on Darwin in both the APR testsuite and httpd
perl-framework. The %lld sprintf format character was incorrectly parsed, and
%ld written instead of the substituted value.
This small patch against APR trunk fixes that:
Index: strings/apr_snprintf.c
Reported many times (by me and others) and many patches suggested. But
apparently no progress on addressing this issue. :^(
https://issues.apache.org/bugzilla/show_bug.cgi?id=48476
On Nov 4, 2010, at 11:46 AM, Sander Temme wrote:
Folks,
I was seeing test failures on Darwin in both the APR
On 11/4/2010 2:46 PM, Sander Temme wrote:
Folks,
I was seeing test failures on Darwin in both the APR testsuite and httpd
perl-framework. The %lld sprintf format character was incorrectly parsed,
and %ld written instead of the substituted value.
This small patch against APR trunk
29 matches
Mail list logo
