On Mon, 2008-05-19 at 20:05 -0400, Bob Rossi wrote:
If you make the change, I'll test out the latest snapshots and all your
fixes for me. Thanks so much Bojan!
Done. And you are welcome.
--
Bojan
On Mon, 2008-05-19 at 20:47 -0400, Bob Rossi wrote:
This is almost correct. It's simply missing the -L to the postgresql/lib
directory. My program failed to link because it couldn't find -lpgport
which lives there.
If fact, PostgreSQL manual
On Tue, 2008-05-20 at 11:21 +1000, Bojan Smojver wrote:
If fact, PostgreSQL manual
(http://www.postgresql.org/docs/8.3/static/libpq-build.html) confirms
that we should be using just --libdir.
BTW, if --libdir alone doesn't cut it for you for some reason, I'll add
--libs back too
On Mon, 2008-05-19 at 18:48 -0700, Chris Darroch wrote:
Personally, I'd suggest just removing it from trunk too ... I'm
not sure exactly how a global cache could be made to work across
multiple databases, since they might be of different versions, etc.
It's not likely to be trivial, I
Here is a patch I've been toying with. Essentially, it does these
things:
- cleans up PostgreSQL detection a bit more
- uses APRUTIL_PRIV_INCLUDES for all CPPFLAGS driver stuff (i.e. we
don't need to expose that to users of APU)
- is careful not to place LDFLAGS of drivers into APRUTIL_LDFLAGS
On Sat, 2008-05-17 at 20:43 -0400, Tom Donovan wrote:
I would be happy to take care of it as soon as I receive commit access. I'm
a new committer, and
the instructions advised patience - so I expect this usually takes some time
to get processed.
I committed something that _may_ work in
On Sun, 2008-05-18 at 11:24 +0200, Ruediger Pluem wrote:
I guess this should now be 0?
Depends, really. If we want things to break when users pass in 0, then
it should be the way it is, provided MySQL returns an error when row it
is given is -1. If we just want to not seek at all, then yes -
On Sun, 2008-05-18 at 12:02 +0200, Ruediger Pluem wrote:
Maybe we should return a driver independent error code in the case that the
row number is 1. A MySQL specific error code might be somewhat confusing
to the user as it might tell him that he used -1 as a row number.
BTW: As far as I see
On Sat, 2008-05-17 at 09:07 -0400, Bob Rossi wrote:
I've been using sqlite3 dbd for some time now. I find that the function
apr_dbd_get_row,
http://apr.apache.org/docs/apr-util/trunk/group___a_p_r___util___d_b_d.html#gd4cdc5f4e8981b93f5a467a8c8a768f1
is 1 based. That is, 1 is the first
On Sat, 2008-05-17 at 06:56 -0400, Bob Rossi wrote:
Huh, I build with --disable-shared --enable-static. Perhaps it doesn't
work in this configuration?
Possibly. Have you tried with --disable-dbd-dso?
--
Bojan
On Sat, 2008-05-17 at 06:56 -0400, Bob Rossi wrote:
char path[80];
Yeah, most likely should be APR_PATH_MAX+1, or something.
--
Bojan
On Sat, 2008-05-17 at 07:21 -0400, Bob Rossi wrote:
Just tried it, my tests pass now, which means this works. Should
--disable-shared force --disable-dbd-dso?
It does disable it - drivers don't work :-)
(Sorry, couldn't resist to be a smartarse).
Seriously, this could be done for
On Sat, 2008-05-17 at 10:03 -0400, Tom Donovan wrote:
I think this is a valid bug.
I agree.
--
Bojan
On Sat, 2008-05-17 at 18:29 -0500, William A. Rowe, Jr. wrote:
+1 and I concur with Tom's suggestion w.r.t. a preferred row offset 1.
Tom, do you want to fix this one or do you want me to do it?
--
Bojan
Quoting Bob Rossi [EMAIL PROTECTED]:
Aren't you worried about how that will break all the existing programs
out there using this interface?
This is one of those damned if we fix it, damned if we don't things :-)
That being said, this is clearly a bug, as APU's DBD is supposed to be
On Fri, 2008-05-16 at 16:32 -0400, Bob Rossi wrote:
I'm looking at dbd_pgsql_open.
http://apr.apache.org/docs/apr-util/trunk/group___a_p_r___util___d_b_d.html#gbddb1fdcb2f8a5f5b83127485c78e8ae
--
Bojan
On Fri, 2008-05-16 at 06:26 -0400, Bob Rossi wrote:
configure:40279: gcc -o conftest -g -Wall -pthread -DLINUX=2 -D_REENTRANT
-D_GNU_SOURCE conftest.c -lcrypt 5
configure:40285: $? = 0
configure:40313: result: -lcrypt
So, the test for crypt actually succeeds. Maybe the whole thing
On Fri, 2008-05-16 at 20:12 -0400, Bob Rossi wrote:
I'm glad to see someone beat me to it!
Glad to be of service :-)
--
Bojan
On Fri, 2008-05-16 at 20:33 -0400, Bob Rossi wrote:
Yes, that worked!
Cool. Thanks for testing!
Do you think this will get into the 1.3 snapshot?
Well, I think it should go in, hence I'll commit to trunk and ask other
committers to comment on in before backporting to 1.3.x/1.2.x. We need
to
On Fri, 2008-05-16 at 19:42 -0500, William A. Rowe, Jr. wrote:
Actually that's half-assed. We have to back out the changes that the DBD
detection causes for LDFLAGS and LIBS, etc, in order to ensure that later
tests aren't bogus.
We already did that, no?
We do it like this in build/dbd.m4:
On Sat, 2008-05-17 at 10:43 +1000, Bojan Smojver wrote:
ask other committers to comment
Well, I didn't have to ask, did I? ;-)
--
Bojan
On Fri, 2008-05-16 at 19:51 -0500, William A. Rowe, Jr. wrote:
No but since you did, my +1.
Thanks.
BTW, there is one place in PostgreSQL detection where we don't return
LDFLAGS and CPPFLAGS back to normal. I'll fix that too.
--
Bojan
On Sat, 2008-05-17 at 10:53 +1000, Bojan Smojver wrote:
BTW, there is one place in PostgreSQL detection where we don't return
LDFLAGS and CPPFLAGS back to normal. I'll fix that too.
Ignore this comment please - this is for the case we we don't fiddle
with CPPFLAGS/LDFLAGS.
--
Bojan
On Fri, 2008-05-16 at 22:43 -0400, Bob Rossi wrote:
I just upgraded to the 1.3 svn snapshot, to test out the new
functionality that was recently added. After I ran my unit tests I
noticed that the function apr_dbd_init() was not working properly for
me. Then I realized it's because this code,
On Thu, 2008-05-15 at 09:08 -0400, Bob Rossi wrote:
Attached is the patch that fixes the problem, what do you think?
Yeah, we do this kind of thing for other databases already. I'll have a
look at it today.
--
Bojan
On Thu, 2008-05-15 at 09:08 -0400, Bob Rossi wrote:
So,
I get a link error, because it needs to link against -lcrypt.
What kind of system do you have? Where does the -lcrypt live on your
system?
BTW, doing the pg_config --libs will not give us the right thing here.
For instance, on my system,
On Thu, 2008-05-15 at 23:18 -0400, Bob Rossi wrote:
Ubuntu 7.04, /lib/libcrypt-2.5.so
OK.
OK, perhaps we should just add -lcrypt to the pg line? I could check to
see if this works on my system if you think this is a good idea.
Hmm, not sure if hardcoding here is the right thing to do. I
On Mon, 2008-05-12 at 17:38 -0500, William A. Rowe, Jr. wrote:
Do folks feel we should release an apr+apu this friday? If 1.3.0 has
settled in, then that is the release. If not, a final 1.2.x release
instead, in the interim?
Given Joe's latest comments regarding --with-ldap, I would be then
On Wed, 2008-05-14 at 10:42 +0800, zengwm wrote:
So making apr_pools.c and linking may require adding some arguments to
the command line to link the library, e.g. -L and -l..
You can try like this:
LDFLAGS=your_flags_here ./configure your_options_here
The run make etc.
--
Bojan
On Mon, 2008-05-12 at 16:10 -0500, William A. Rowe, Jr. wrote:
Like Roy, I'm frustrated with aprutil's dependency madness, and I'm working
right now on abstracting out apu-util into a loadable module. At this point
a --with-ldap build on linux FC8 is producing this pile of crap as bindings
On Mon, 2008-05-12 at 16:39 -0500, William A. Rowe, Jr. wrote:
Which is my point, a loadable apr_ldap.so stub which is loaded at runtime
by applications which need it is the simplest solution. With the existing
apr_ldap_init function, this should all be transparent.
Ah, sorry :-( I thought
On Mon, 2008-05-12 at 12:45 -0500, William A. Rowe, Jr. wrote:
Is anyone else seeing testreslist spin for an excessive amount
of time? This is on
Linux 2.6.24.5-85.fc8 #1 SMP Sat Apr 19 12:39:34 EDT 2008 i686 i686 i386
GNU/Linux
Ditto here (i.e. just confirming your result).
--
Bojan
On Sun, 2008-05-11 at 21:35 +0200, Ruediger Pluem wrote:
This already works if you compile apr-util (trunk / 1.3) with
--enable-dbd-dso
Maybe that should be the default, combined with disabling of
MySQL/Oracle drivers by default due to possible downstream licensing
issues?
--
Bojan
On Sun, 2008-05-11 at 18:36 -0500, William A. Rowe, Jr. wrote:
Are there concerns
that this is either insufficiently portable or stable enough to serve as
our 1.3 default?
Not sure about portability, but it is as stable as linking the drivers
directly.
--
Bojan
On Sun, 2008-05-11 at 20:35 -0400, Tom Donovan wrote:
Maybe that should be the default, combined with disabling of
MySQL/Oracle drivers by default due to possible downstream licensing
issues?
I agree that --enable-dbd-dso should be the default (presuming the
platform supports dso), but
On Sun, 2008-05-11 at 21:08 -0500, William A. Rowe, Jr. wrote:
Yes - drop any automatically detected dbd provider who's license is more
restrictive than APR's. If someone such as a linux distro (GPL) wants
to turn back on the mysql dbd, this is their prerogative.
And enable dbd-dso by
On Mon, 2008-05-12 at 12:55 +1000, Bojan Smojver wrote:
In r655174 and r655403 of the trunk now.
Backported to 1.3.x in r655404.
--
Bojan
On Mon, 2008-05-12 at 11:19 +0800, zengwm wrote:
apr_pCalloc() calls apr_palloc() to do the memory allocation in the
pool. It aligns the 'size' parameter before calling apr_palloc(). And
the size is aligned again in apr_palloc().
Why 'size' has to be aligned twice? Can the first alignment (
On Sat, 2008-05-10 at 13:58 -0700, Roy T. Fielding wrote:
This is a showstopper. It must be fixed in 1.3.x before release.
My fix is also incomplete: All of the other DBD drivers that do not have
redistributable client libraries must also default off. Oracle is one
for sure -- I am unaware
On Thu, 2008-05-01 at 21:25 +0100, Christopher Key wrote:
I'm not sure whether this has been covered already, and whether it needs
to go in during a major release, but is there any chance of adding
apr_int8_t and apr_uint8_t typedefs?
AFAICT, this was left off with Garrett asking for a bug
On Mon, 2008-04-28 at 17:33 -0500, William A. Rowe, Jr. wrote:
Interesting thought, keep in mind the other half of the issue is the number
of times we consume generate_random_bytes ourselves from other functions,
you'll have to suggest which should be pseudo, which should be truly random
and
On Thu, 2008-05-01 at 18:05 -0500, William A. Rowe, Jr. wrote:
So no, I would not change the manner that UUID's are generated to urandom.
generate_random_bytes is defined to provide the greatest entropy we can
obtain. It is not, after all, generate_psuedorandom_bytes.
OK, thanks. I'll update
On Fri, 2008-05-02 at 02:56 +0300, Lucian Adrian Grijincu wrote:
1. Some function in APR's uuid generator falls back to rand(3) if
apr_generate_random_bytes returns an error. ...
2. E2fsprogs on which other major open source UUID generators are
supposed to be based on (at least according to
On Tue, 2008-04-29 at 22:41 -0300, César Leonardo Blum Silveira wrote:
I'm really sorry if this is annoying, but no one gave any feedback on
this. Hasn't anyone liked the idea? Or maybe I should log this on
bugzilla?
I think this in unlikely to be included, as it changes the usual APR
On Wed, 2008-04-30 at 22:51 +0200, Branko Čibej wrote:
He's proposing to make NULL a
well-defined parameter for this function, not an incorrect one.
Yeah, that's another way to see it. I was referring to the current
behaviour, where NULL is considered an incorrect value (together with a
value
Does anyone mind if I apply the fix mentioned in the bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=44881
--
Bojan
On Mon, 2008-04-28 at 10:12 -0500, William A. Rowe, Jr. wrote:
It's a mailing list, please don't make people chase down a link (remember
some of us read our email detached from the web). Citing the patch and
bug's subject is a bare minimum :)
OOPS, sorry :-(
BTW, the same thing was done in
On Fri, 2008-04-25 at 15:01 -0700, Roy T. Fielding wrote:
On Apr 25, 2008, at 2:52 PM, [EMAIL PROTECTED] wrote:
==
--- apr/apr/trunk/file_io/unix/copy.c (original)
+++ apr/apr/trunk/file_io/unix/copy.c Fri
On Sat, 2008-04-26 at 08:07 +1000, Bojan Smojver wrote:
I'm not sure that is portable C. Is the compiler guaranteed to
optimize that
into a constant?
I would think so. BUFSIZ is defined as constant, as well as
APR_FILE_DEFAULT_SIZE. But, I'll check again...
The book says
On Fri, 2008-04-25 at 15:42 -0700, Roy T. Fielding wrote:
I just checked by KR 1st edition and it allows constants
possibly connected by the ternary operator. So, unless we find a
specific compiler that doesn't accept it, I think we can leave it as is.
Too late... Already changed :-)
--
On Thu, 2008-04-24 at 13:08 +1000, Bojan Smojver wrote:
Maybe we should have a private #define that takes max of
APR_FILE_DEFAULT_BUFSIZE and BUFSIZ and then uses that instead of just
BUFSIZ?
For instance...
--
Bojan
Index: include/arch/win32/apr_arch_file_io.h
On Thu, 2008-04-24 at 10:52 +0200, Branko Čibej wrote:
The copy buffer size should be a different
private value.
Feel free to adjust.
Reporter of the bug was happy with 4k - that's how the value was chosen,
a opposed to 512 bytes he'd get on his platform.
--
Bojan
On Wed, 2008-04-23 at 21:29 +0200, Erik Huelsmann wrote:
Performance would benefit greatly from using APR_FILE_BUFSIZE, which
is defined as 4096 bytes.
I'm not sure if someone is planning to address this for Windows, but
BUFSIZ on glibc systems is 8k and Unix systems seem to have it set to
1k.
On Fri, 2008-04-11 at 16:41 +0200, William A. Rowe, Jr. wrote:
I'd like to proceed with this at the end of the weekend, unless
there is significant objection that we can't resolve.
+1 and thanks!
--
Bojan
On Tue, 2008-04-01 at 10:49 -0700, David Glasser wrote:
Is this likely to ever be released in the 0.9 and/or 1.2 branches?
Not likely, because versioning rules forbid that:
http://apr.apache.org/versioning.html
If
not, is apr-util 1.3 actively under development?
Yes and it will be released
On Thu, 2008-01-31 at 10:36 -0500, Scott Sanders wrote:
AuthDBDUserPWQuery to SELECT pwd2 FROM users WHERE email=%s AND
active=1.
It is Apache's mod_authn_dbd that does the above.
This has got to be a bug in the apr_dbd_mysql code
Could be. It could also be something to do with
On Wed, 2008-01-30 at 11:20 -0500, Scott Sanders wrote:
checking mysql.h usability... yes
checking mysql.h presence... yes
checking for mysql.h... yes
checking for mysql_init in -lmysqlclient_r... no
^
checking mysql/mysql.h usability... yes
Quoting Paul J. Reder [EMAIL PROTECTED]:
I addressed the comments and haven't heard back from anyone
(Bojan or others). I can't commit to APR and can't commit the
Apache portion until the APR part has been committed. I know
folks were busy with the latest APR update... Has the dust
settled?
On Fri, 2007-11-23 at 10:22 -0600, William A. Rowe, Jr. wrote:
are we looking at a 1.3 iteration before we
make such radical changes as 2.0? If so, when? I'd love to see 1.3
come together over the next month or two for those who don't want to
wait on/depend upon such a major release bump.
I
On Thu, 2007-11-29 at 16:43 -0500, Bob Rossi wrote:
I'm a newb with database connections, so forgive me if this is a simple
question. I'm looking into using the dbd routines to open connections
to a database. The routines are here,
On Thu, 2007-11-29 at 17:34 -0500, Bob Rossi wrote:
OK, perhaps we could have some high level documentation on the webpage
for the dbd documentation that describes which databases it works with?
On Mon, 2007-11-26 at 11:55 -0800, Ryan Phillips wrote:
What is the benefit in chunking a library?
Lower memory footprint, among other things.
--
Bojan
On Sun, 2007-11-25 at 23:11 +, [EMAIL PROTECTED] wrote:
liUnix Source:
+a href=[preferred]/apr/apr-0.9.17.tar.gzapr-0.9.17.tar.gz/a
+a href=[preferred]/apr/apr-0.9.17.tar.bz2apr-0.9.17.tar.bz2/a
I can't see these in dist. Have they been copied yet?
--
Bojan
On Wed, 2007-11-21 at 21:32 +0100, Ruediger Pluem wrote:
All tests past with the exception of the following error for sqlite2:
prepared select
Prepare statement failed!
(null)
Error in prepared select: rc=70023
prepared query
Prepare statement
On Tue, 2007-11-20 at 18:45 -0600, William A. Rowe, Jr. wrote:
Please provide your input to release the tarball candidate
[-1] APR-util 1.2.12
Fedora 8, i686 and x86_64, testreslist still hangs exactly the same as
with 1.2.11. I guess r595990 didn't fix that problem after all.
PS. Tested
On Thu, 2007-11-22 at 09:28 +1100, Bojan Smojver wrote:
I did wait for about 5 minutes before killing it. OK, I'll try again.
Ah, yes. I should have waited another minute!
Passed test on both architectures, so my vote is now +1.
Sorry about the false alarm.
--
Bojan
On Thu, 2007-11-22 at 00:22 +0200, Graham Leggett wrote:
Am I correct in understanding this is no longer true (since v1.0)?
At least in Fedora/RHEL, it's been a successful system-wide library for
a long time now.
--
Bojan
On Thu, 2007-11-22 at 00:25 +0200, Graham Leggett wrote:
Did it hang, or did you abort before it was done?
I did wait for about 5 minutes before killing it. OK, I'll try again.
--
Bojan
On Mon, 2007-11-19 at 20:38 +0800, Learning apr wrote:
I use the function:
apr_dbd_transaction_start(driver, pool, sql,transaction);
to start a transaction.
But when I close this transaction with the function:
apr_dbd_transaction_end(driver, pool, transaction);
It always gives the error
On Mon, 2007-11-19 at 21:47 +0100, Ruediger Pluem wrote:
I haven't commited for testdate so far.
Yeah, sorry. I confused a patch sent to the list with a commit. I'll
blame it on caffeine deficiency, although old age is more likely ;-)
--
Bojan
On Thu, 2007-11-15 at 16:26 -0500, William A. Rowe, Jr. wrote:
Please provide your input to release.
[+1] APR-0.9.17
[+1] APR-1.2.12
[-1] APR-util-1.2.11
[ ] APR-iconv-1.2.1
Fedora 8, i686 and x86_64.
Both apr-0.9.17 and apr-1.2.12 fail SHM tests:
0.9.17:
Quoting Paul J. Reder [EMAIL PROTECTED]:
The patches have been updated to address the issues pointed
out below (thanks Bojan).
New contents at the old links:
http://people.apache.org/~rederpj/APR-trunk_rebind.diff
http://people.apache.org/~rederpj/Apache-trunk_rebind.diff
Cool.
Question:
On Wed, 2007-11-14 at 20:02 -0500, Paul J. Reder wrote:
The APR portion of the patch:
http://people.apache.org/~rederpj/APR-trunk_rebind.diff
Just a few comments (without going into what the patch does):
- you probably want to rename apr_ldap_init_xref_lock() to
apr_ldap_xref_init() instead
On Tue, 2007-11-13 at 00:21 -0200, Davi Arnaut wrote:
Missing for the #else case.
Fixed in r594422.
It's the functions supposed to be publicly used? If yes, you should
export then properly (apr_dbd.h). If not, it would be better to extend
apr_dbd_t with lock and unlock methods which can
On Tue, 2007-11-06 at 03:08 +0200, Lucian Adrian Grijincu wrote:
What purpose does rv = have in this code?
the apr_status_t isn't used anywhere in there
A leftover-cut-n-paste purpose? :-)
--
Bojan
On Tue, 2007-10-30 at 22:54 +, [EMAIL PROTECTED] wrote:
Introduce apr_dbd_open_ex()
Given that nobody complained to the patch I sent to the list a while
ago, I decided to rely on CTR. Please let me know if any breakage was
introduced with this commit.
NOTE: FreeTDS driver needs to be
Quoting Bojan Smojver [EMAIL PROTECTED]:
Perhaps something like this (compiles but untested)...
And, of course, I've forgotten that we now have FreeTDS driver too.
--
Bojan
On Fri, 2007-10-19 at 15:05 +1000, Bojan Smojver wrote:
Yeah, that's been the problem of the 1.2 API. In 1.3, we cannot do it
with the same function (API/ABI backward compatibility), but we can
introduce another function (e.g. apr_dbd_open_ex()) that does return an
error.
Perhaps something
On Fri, 2007-10-19 at 14:52 +1000, Ian Holsman wrote:
yes thats' debugging, but it would be nice to be able to return the
error message when it fails to connect. the 'close' after the real_open
removes the error so all you get is the internal error code.
Yeah, that's been the problem of the
On Fri, 2007-10-19 at 12:31 +1000, Ian Holsman wrote:
{flags, NULL},
+{multi, NULL},
Shouldn't this be part of flags?
+if (fields[8].value != NULL) {
sql-fldsz = atol(fields[7].value);
The above line should also be patched (i.e. this is now index 8, not 7).
On Fri, 2007-09-21 at 11:55 +, [EMAIL PROTECTED] wrote:
Author: jfclere
Date: Fri Sep 21 04:55:06 2007
New Revision: 578076
URL: http://svn.apache.org/viewvc?rev=578076view=rev
Log:
Oops was using the wrong variable.
Apparently, this and r578028 is causing people to not be able to
On Mon, 2007-09-24 at 22:27 -0700, Aliya Harbouri wrote:
I'm suspicious of that
/usr/local/mysql/lib/mysql/libmysqlclient_r.la; I expected just
-lmysqlclient_r.
That was a recent addition to the trunk. I'm thinking PHP probably isn't
using libtool for linking there and it's trying to link a
On Thu, 2007-09-20 at 09:39 +, [EMAIL PROTECTED] wrote:
Author: jfclere
Date: Thu Sep 20 02:39:27 2007
New Revision: 577654
URL: http://svn.apache.org/viewvc?rev=577654view=rev
Log:
Use the mysql libtool library when available.
(Otherwise it breaks on one of the HP-UX where I am
On Mon, 2007-09-17 at 12:29 -0700, Kristis Makris wrote:
checking netinet/sctp.h usability... no
Can you have a look in config.log to see what actually happened at the
above points of configuration? There will be some output about what
failed exactly.
--
Bojan
On Mon, 2007-09-17 at 16:06 -0700, Kristis Makris wrote:
I see the following. Perhaps I'm missing some headers ??
There is a macro called APR_FLAG_HEADERS that checks various headers
(called from configure.in, defined in build/apr_common.m4), which
doesn't seem to be taking into account the
On Mon, 2007-09-17 at 16:57 -0700, Kristis Makris wrote:
I don't know. But APR_CHECK_SCTP is indeed called, so the results should
be in the attached config.log.
Seems to be OK:
---
configure:41928: checking whether SCTP is supported
configure:41970: gcc -o
On Thu, 2007-09-13 at 09:14 +0100, Joe Orton wrote:
It looks like the range of the test is supposed to be limited by that of
a 32-bit time_t, given the range of dates in year2secs. If you make
that array simply an array of time_t or apr_int32_t, and drop the
INT64_C() casts, does it work?
On Sat, 2007-09-08 at 22:04 +0300, Lucian Adrian Grijincu wrote:
Can't this be automated (aka, when a new tag in 1.2 or 0.9 is created
to update the docs and when a commit in trunk/include takes place to
update the docs?
I guess it could be automated. I just logged into my account on
On Sun, 2007-09-09 at 15:03 -0700, Sander Temme wrote:
./config.nice --with-mysql=/usr
Yeah, that's pretty much like the default, as long as /usr/bin is in
your path (which on most system it is).
./config.nice --with-mysql=/usr/bin/mysql_config
That won't work. You cannot point to the config
Just bumped into this today, but it seems that in function
gm_timestr_822() of testdate.c, we are stuffing a 64-bit value
(apr_time_t) into something may be a lot shorter (time_t). So, errors
start occurring and test fails (Fedora 7, i686). I was thinking that we
should patch the test along the
On Sun, 2007-09-09 at 21:35 -0700, Sander Temme wrote:
Aaaah! What about the other tests later in the sequence? Usually
test targets complete every test, regardless of failures.
The problem was that nobody ever knew that any of the tests actually
failed, because make wouldn't stop.
The
On Mon, 2007-09-10 at 14:53 +1000, Bojan Smojver wrote:
The problem was that nobody ever knew that any of the tests actually
failed, because make wouldn't stop.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42725
--
Bojan
On Mon, 2007-09-10 at 00:03 -0500, William A. Rowe, Jr. wrote:
The full list of failures should be reported, otherwise
you only discover the first flaw and have no clue of the scope of the issue.
OK, we can do that too, it's not difficult.
--
Bojan
On Mon, 2007-09-10 at 05:32 +, [EMAIL PROTECTED] wrote:
Modified: apr/apr-util/trunk/test/testdate.c
Reverted in r574137. This was committed by accident.
--
Bojan
On Sun, 2007-09-09 at 22:15 -0700, Sander Temme wrote:
Make shouldn't stop, but run all the tests, quietly, and, if there
are failures, emit a list of those failures and fail the target. At
the end, not at the first failure.
Hopefully r574134/5 should be better. Any dramas, let me know.
On Fri, 2007-09-07 at 12:38 -0700, Sander Temme wrote:
If you look at the (long) link line at the bottom, you'll see that
it's picking up -L/usr/lib/mysql -lmysqlclient_r , and the root cause
of that is probably somewhere in configure where it decides to use
the system MySQL despite the
On Wed, 2007-09-05 at 17:07 -0500, William A. Rowe, Jr. wrote:
I'm just pondering, does this violate our ABI rules?
Possibly. On the other hand, people that have been plonking the MySQL
driver and compiling the result (for which we provided the harness)
would have had that problem already.
We
On Thu, 2007-09-06 at 00:02 +0100, Nick Kew wrote:
Aha! Yes, I think that was the plan when we discussed dropping the
mysql driver in. Default it to off in the build, and alert users to
the fact.
Shall do.
--
Bojan
On Tue, 2007-09-04 at 14:12 +0100, Nick Kew wrote:
apr_dbd_mysql is the familiar MySQL driver.
Wonderful! Thanks Nick!
I'm working on cleaning up the checked in driver (trunk) from all that
stuff (i.e. #ifdef's etc.) that is 1.2.x specific. At the same time, if
there is support for this, I can
On Wed, 2007-09-05 at 10:52 +1000, Bojan Smojver wrote:
At the same time, if
there is support for this, I can backport similarly cleaned (just in the
opposite direction) driver to 1.2.x.
Ready to commit, just say the word :-)
--
Bojan
501 - 600 of 930 matches
Mail list logo
