Quoting Bojan Smojver [EMAIL PROTECTED]:
We can then handle failures by having a wait loop inside
transaction_start(), just like we do with select/query.
Actually, it is dbd_sqlite3_query() that's going to do that for us, so
all we need is just BEGIN IMMEDIATE.
--
Bojan
On Thu, 2006-06-22 at 14:31 -0700, Rick Keiner wrote:
After some problems I was having with cannot start a transaction
within a transaction problem with SQLite3, I came across this and I
think a check should go in the transaction handling for busy
conditions in the end transaction.
On Wed, 2006-11-29 at 06:23 -0600, William A. Rowe, Jr. wrote:
Please review and vote on those you have time to - reply once or four times,
just review those you can as you can; http://apr.apache.org/dev/dist/
+1/-1 Release
[ ] apr-1.2.8
[ ] apr-util-1.2.8
[ ]
Does anyone know what's the status of this code? Anything in there that
can be used by callers? Nothing seems to be documented in doxygen, so
I'm not sure if this is just for APR internal use...
--
Bojan
On Tue, 2006-11-28 at 21:24 -0600, William A. Rowe, Jr. wrote:
But given than RC4/RC5 are dead (RC4 needs to be killed ASAP with apr 2)
it seems we really should export and document them for general use with
apr 1.3
I see a whole bunch of functions named something like apr__SHA256_Data
etc.
On Thu, 2006-11-23 at 23:36 +, Jorge Bastos wrote:
I recompiled libapr and libaprutil from svn, the last 0.3.0.
I use the apache 2.2.3 version from the debian packages.
What could it be?
Your best bet would be to run the whole thing in gdb and then stop in
dbd_mysql_prepare() and
Quoting Jorge Bastos [EMAIL PROTECTED]:
AuthDBDUserPWQuery select password from users where username='%s'
Have you tried without the apostrophes? Like this:
AuthDBDUserPWQuery select password from users where username=%s
--
Bojan
On Thu, 2006-11-09 at 10:26 +, Joe Orton wrote:
I remain unconvinced ;)
OK, no worries.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
2) Create yourself a global pool to load DSOs into, and do so early
enough that it'll always be destroyed last.
We discussed some patches along those lines around the end of
September. Would that be the approach that the list would approve? Or
are
On Wed, 2006-11-08 at 11:00 -0600, William A. Rowe, Jr. wrote:
I'm primarilly interested in making a 1.2 tarball to vote on in 48
hours because we have fixed a number of bugs.
That would be awesome, thanks.
--
Bojan
Quoting Ioan Popescu [EMAIL PROTECTED]:
If they're here to stay, could someone tell me what advantages there are to
using them instead of malloc()/free()? Regardless of portability.
- well suited for request/response situations (i.e. limited object lifetime)
- faster than many malloc()
Quoting Bojan Smojver [EMAIL PROTECTED]:
Apache has a notion of maximum number of requests a child process will
handle. This can help with memory leaks, as processes simply get
recycled after a while, therefore freeing any long lifetime memory
that may have leaked in the child during its
Quoting Bojan Smojver [EMAIL PROTECTED]:
And here is the patch that does exactly that. I'll follow this up with
another e-mail where I'll include some other, related stuff. This is
due to list size restrictions.
As promised...
--
Bojan
Index: apr_dbd_mysql.c
On Fri, 2006-09-29 at 16:15 -0400, Garrett Rooney wrote:
One other thing that occurs to
me though, you need to ifdef around the declaration of the dso mutex,
if we don't have threads that type won't be declared.
Ah, yes. Sorry.
--
Bojan
On Wed, 2006-09-27 at 12:56 -0500, William A. Rowe, Jr. wrote:
or, to the project;
do we want to change the very nature of collecting individual copyright
statements in NOTICE from all major contributors? Do we believe this
would encourage other worthwhile contributions?
After
On Wed, 2006-09-27 at 22:56 -0400, Garrett Rooney wrote:
Just for the record, nobody is saying that Sun shouldn't keep
copyright on the code. None of our CLAs involve a copyright
assignment, so no matter what happens Sun (just like any contributor)
will keep the copyright on whatever code
On Mon, 2006-09-25 at 09:27 +0100, Joe Orton wrote:
That still has to wait for a minor version bump; the versioning rules
don't permit API extensions in patch releases:
Changes to the API, to the signatures of public functions, or to the
interpretation of function parameters is not
On Mon, 2006-09-25 at 11:28 -0700, Chris Darroch wrote:
I guess my remaining hestitation relates to the fact that there's
a lot of reliance on atoi() and friends here, and that with certain
drivers you might see numeric data converted from the DB's internal
format to a string (because the
Here is a backport of the _prepare() unified parsing support to
1.2.x and with it a more explicit support for SQL types when using
_p[v]select/query.
Please review, test, flame etc.
--
Bojan
Index: include/apr_dbd.h
===
---
Quoting Garrett Rooney [EMAIL PROTECTED]:
Sure, it's not
adding any new functions or anything, but it's changing the semantics
of the function parameters in a non-compatible way.
I tried no to do this, actually. The idea was that everything that
works in 1.2.x before this patch should work
Quoting Garrett Rooney [EMAIL PROTECTED]:
I guess I'm not seeing how adding a bunch of new format strings isn't
changing anything... Am I just misunderstanding how the patch works?
It looks like it replaces the existing format string parsing with all
new parsing. Is it just that the new
Quoting Garrett Rooney [EMAIL PROTECTED]:
Ok, in that case it sounds good to me.
Cool. Thanks for your input.
Given that there has been some talk on the list of the 1.2.8 release
recently, I will wait until other people say something about this
before any changes are made to the
On Tue, 2006-09-19 at 10:39 -0400, Garrett Rooney wrote:
I would avoid locking when pool isn't NULL,
Not exactly sure what you mean. The patch does this in all places where
mutex is supposed to get locked:
---
+#if APR_HAS_THREADS
+if (!pool) {
+
On Tue, 2006-09-12 at 10:40 -0400, Garrett Rooney wrote:
I would prefer to leave the global pool alone, and just create a
separate subpool and mutex around that, since that keeps the global
pool isolated to apr_pools.c, rather than making it accessed from
multiple parts of the source tree.
On Mon, 2006-09-11 at 10:48 -0400, Garrett Rooney wrote:
If we're going to go
based off of a NULL pool argument, I'd prefer to allocate out of a
known to be safe global pool, which we can create as part of
apr_initialize, then cleanups will happen normally at shutdown time.
OK, no worries.
I
Quoting Bojan Smojver [EMAIL PROTECTED]:
Ah well, here is a version with calloc(). Since we wouldn't
be doing anything with pools here and it would be for the duration of
the process, I guess we should be OK.
Any thoughts on this approach?
I'm not sure if I missed some e-mails from the list
On Tue, 2006-09-05 at 23:39 -0700, Chris Darroch wrote:
Firstly, Bojan, thank you for all the work on these patches! I read
through them last week and reviewed quickly your latest updates, and
really, I don't see much to discuss -- it's all looking very close to
what I might hope for!
No
Quoting Bojan Smojver [EMAIL PROTECTED]:
We could have others - for instance apr_dbd_file_t (for
APR_DBD_TYPE_BFILE), which could look something like this:
struct apr_dbd_file {
apr_file_t *file; /** file to read the data from */
apr_size_t size;/** size to read */
apr_off_t
Quoting Bojan Smojver [EMAIL PROTECTED]:
In the patches, I return APR_ENOENT from datum_get() if I find a null
value, so no need for apr_dbd_is_null() call. Except that I've forgotten
to do this for SQLite2... Sorry, I'll try to fix that.
Here is another tarball with the patches
On Tue, 2006-09-05 at 11:54 +0600, Duleepa Karunaratne wrote:
I want to run my .jsp and .jsf from the apache server, not starting two
servers (apache and tomcat) separately. Is there any way to integrate
the Tomcat server to the Apache server so that I can run those from the
same location.
On Fri, 2006-08-25 at 11:05 -0700, Chris Darroch wrote:
I'm going to have some travel
next week so I'll take it with me to review on the plane trips.
Awesome, thanks.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
So you're saying that it should be impossible to use pools within a
DSO loaded module without either absolute control over when those
pools were created relative to the one that loads the DSO or taking
extreme measures within the DSO to work around the
Quoting Ruediger Pluem [EMAIL PROTECTED]:
So the pointers to the literals where invalid. Ouch.
Right. I see that my assumption about relying on things after
apr_dso_unload()/apr_dso_load() cycle was incorrect.
I'm not sure how to address that at all. I mean if on Linux pointers
change
Quoting Garrett Rooney [EMAIL PROTECTED]:
That is in fact what the Subversion code currently does.
I do similar things as well in my code. It just a bit easier as I
control the lot :-)
The problem
is that you need to create the global DSO code sufficiently early in
the application's
Quoting Garrett Rooney [EMAIL PROTECTED]:
I think we're talking about the same thing here.
Yep.
What I want is an
API that says load this DSO, and don't unload it until we exit.
That would make all my problems (in this particular are anyway) go
away.
If this is a per-process thing (i.e.
Quoting Bojan Smojver [EMAIL PROTECTED]:
Would that do it?
Like the attached, perhaps?
--
Bojan
Index: include/apr_dso.h
===
--- include/apr_dso.h (revision 432465)
+++ include/apr_dso.h (working copy)
@@ -50,9 +50,10
Quoting Bojan Smojver [EMAIL PROTECTED]:
Like the attached, perhaps?
Not quite.
The caller would have no way of determining the size of the
apr_dso_handle_t, therefore it would not be possible to allocate this
structure. Ah well, here is a version with calloc(). Since we wouldn't
On Sun, 2006-08-13 at 13:57 -0700, Spence wrote:
Reposted in Apache HTTP Server - Users
(http://www.nabble.com/DBD%3A-driver-tf2100248.html)
Sorry for the OT post.
The --with-mysql=DIR configure option may have been useful there.
--
Bojan
On Tue, 2006-08-15 at 06:58 +1000, Bojan Smojver wrote:
PS. Due to size issues on the list, I'll send the MySQL patch in a
separate e-mail.
MySQL patch.
--
Bojan
Index: apr_dbd_mysql.c
===
--- apr_dbd_mysql.c (revision 51
On Thu, 2006-08-10 at 19:52 -0700, Spence wrote:
[Thu Aug 10 19:30:35 2006] [crit] (70023)This function has not been
implemented on this platform: DBD: driver for [DBDriver unset] not available
[Thu Aug 10 19:30:35 2006] [crit] (70023)This function has not been
implemented on this platform:
Quoting Keisuke Nishida [EMAIL PROTECTED]:
apr_dbd_sqlite3.c:dbd_sqlite3_get_name() in the trunk crashes when
res-next_row is NULL. The patch below fixes the problem.
Thanks for the patch. Once I get to the machine where I can do this,
I'll commit to trunk and backport to 1.2.x.
--
Bojan
On Fri, 2006-06-30 at 01:37 -0700, Alex Dubov wrote:
Well, you are continuing to be non-productive.
Whatever. I'll let others untangle this one.
--
Bojan
Quoting Alex Dubov [EMAIL PROTECTED]:
I'm not going to use strings for this stuff. Period.
You obviously haven't read my e-mail.
--
Bojan
Quoting Alex Dubov [EMAIL PROTECTED]:
Ok, after reading it another time: your mail contains
no useful information.
OK. I thought it may be important to you that we do things to the APR
that everyone can use. Never mind then...
--
Bojan
On Tue, 2006-06-27 at 13:01 -0400, DEBIN GAO wrote:
I'm looking at
#define APR_TIME_T_FMT APR_INT64_T_FMT
in apr.hnw, and wonder if it should be
#define APR_TIME_T_FMT APR_UINT64_T_FMT
typedef apr_int64_t apr_time_t
AFAIK, these things can legitimately be less than zero.
--
Bojan
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
AFAIK, these things can legitimately be less than zero.
Depends, can only be less than zero if dealing with pre-1970 dates.
Yes, that's how I understood that as well. Which of course is quite
legitimate (i.e. I'd be willing to bet many
On Thu, 2006-06-22 at 14:31 -0700, Rick Keiner wrote:
After some problems I was having with cannot start a transaction
within a transaction problem with SQLite3, I came across this and I
think a check should go in the transaction handling for busy
conditions in the end transaction.
Quoting Chris Darroch [EMAIL PROTECTED]:
int i=0;
apr_dbd_pvselect([other args],i,NULL);
Heh ... well, yes, that's true. But isn't that drifting rather
far away from the works like sprintf() idea?
Yes, I was just being a smartarse :-) Already fixed - thanks for
pointing out the
Quoting Chris Darroch [EMAIL PROTECTED]:
Maybe someone with APR commit access (Nick, Bojan?) could review
the patch I've attached to PR 37664 and commit it to trunk;
Nick is on the ball here, so I'll smartly leave this one alone (i.e. I
have no idea how Oracle works :-).
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
I would stick to the current meaning, mostly because of this:
---
if (!trans)
return APR_DBD_TRANSACTION_COMMIT;
---
In essence, the function returns the mode in force after the call
(actually
On Mon, 2006-06-12 at 17:51 -0400, Chris Darroch wrote:
Hmm ... I'm quite sure what to make of that. Should it be documented,
That is for sure.
Moreover, if this is the desired behaviour, then migrating from
expecting purely string arguments in apr_dbd_pvquery() and
On Tue, 2006-06-13 at 10:25 +1000, Bojan Smojver wrote:
It is easy to make that change in PostgreSQL and SQLite drivers (i.e. to
remember the number of args parsed in _prepare). People can keep passing
NULL as the last argument in pvquery/pvselect - they shouldn't get hurt.
If nobody objects
On Tue, 2006-06-13 at 03:49 +, [EMAIL PROTECTED] wrote:
Author: bojan
Date: Mon Jun 12 20:49:54 2006
New Revision: 413798
URL: http://svn.apache.org/viewvc?rev=413798view=rev
Log:
Don't expect variable argument list to end with NULL
for PostgreSQL and SQLite3 DBD drivers. Count
On Fri, 2006-06-09 at 22:28 -0400, Chris Darroch wrote:
(I'm actually a little surprised by the use of va_arg() in
the other drivers and also in apr_brigade.c, where it seems like a
NULL return is expected after iterating past the last argument.
I didn't know va_arg() would do that ... the
On Sat, 2006-06-10 at 09:58 +0100, Nick Kew wrote:
Isn't that just the support for different argument formats: %d, %f
in an argument format string? I thought oracle was setting a precedent
others could follow in that regard, since the original drivers only
supported %s but were intended to
Quoting Chris Darroch [EMAIL PROTECTED]:
3) Error reporting via a standard set of APR_DBD_* error codes
Switching to APR_DBD_* error codes will *probably* break binary
compatibility requirements for 1.x (i.e. int will become apr_status_t,
which is probably the same thing, but I'm not sure
Quoting Chris Darroch [EMAIL PROTECTED]:
I can confirm the following, as tested with all four of the
p[v]query|select() functions (since the Oracle driver treats them
each separately):
Database | Explicit ROLLBACK | Ignore TXN errors
oracle
Quoting Chris Darroch [EMAIL PROTECTED]:
But, suppose someone thinks they can do this safely:
sql = apr_pstrdup(p, SELECT foo FROM bar WHERE baz = ',
apr_dbd_escape(user_input), ');
apr_dbd_prepare(driver, p, handle, sql, NULL, stmt);
If user_input happens to contain a
On Wed, 2006-06-07 at 09:56 +0100, Joe Orton wrote:
This is really still a long way from properly - both the old and new
code has undefined behaviour because of the function cast.
I noticed these casts in other cleanup registrations, so I just assumed
they were safe. What did you have in
On Wed, 2006-06-07 at 21:02 +1000, Bojan Smojver wrote:
I noticed these casts in other cleanup registrations, so I just assumed
they were safe. What did you have in mind? A wrapper function?
Like this?
--
Bojan
Index: dbd/apr_dbd_sqlite2.c
On Wed, 2006-06-07 at 12:29 +0100, Joe Orton wrote:
Yup, exactly what I had in mind ;)
Cool. I have those little functions all over my own code, but I never
actually thought about their usefulness until now. Well, you learn
something new every day :-)
--
Bojan
On Wed, 2006-06-07 at 11:34 +, [EMAIL PROTECTED] wrote:
Don't cast cleanup function, provide wrappers instead.
I'll audit other DBD drivers too.
--
Bojan
On Wed, 2006-06-07 at 12:44 +0100, Joe Orton wrote:
Another useful thing that can be done in general is to do e.g.
static apr_status_t blah(void *data)
{
char *foo = data;
the_function(foo)
since passing a variable of the right type to the function rather than
just void * gives
On Wed, 2006-06-07 at 12:58 +0100, Joe Orton wrote:
This is not really a concern with use of sqlite2, but I think it's a
good idea in general ;)
Yep, seems clever to me.
--
Bojan
Quoting Joe Orton [EMAIL PROTECTED]:
This is really still a long way from properly - both the old and new
code has undefined behaviour because of the function cast.
The following code, from apr_dbd.c, probably won't have an easy fix
like the drivers did:
Quoting Bojan Smojver [EMAIL PROTECTED]:
The following code, from apr_dbd.c, probably won't have an easy fix
like the drivers did:
The only thing that springs to mind is to change apr_dbd_internal.h to read:
apr_status_t (*end_transaction)(void *trans);
And then patch individual drivers
Quoting Bojan Smojver [EMAIL PROTECTED]:
Database | Explicit ROLLBACK | Ignore TXN errors
oracle | Not tested| Not tested
Above also appears to be Yes and Yes (Oracle 10g). Someone
Quoting Bojan Smojver [EMAIL PROTECTED]:
OK, here is the summary:
Oh, and I will adjust the transaction documentation some more before
the commit, so that users can tell what the logic is.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Database | Explicit ROLLBACK | Ignore TXN errors
sqlite2 | Not tested| Not tested
Make the above Yes and Yes.
--
Bojan
Quoting Philip M. Gollucci [EMAIL PROTECTED]:
A patch against the latest version of MySQL driver is also attached.
I've got some relative good mysql foo. I can lend a hand against
MySQL 3.23, 4.0.18, 4.0.26, 4.1.20, 5.0.21, 5.1.9-beta testing if needed.
Only those versions? ;-)
Seriously,
Quoting Rick Keiner [EMAIL PROTECTED]:
Any idea what the time frame is on this?
Basic tests with PostgreSQL query/pquery under
APR_DBD_TRANSACTION_IGNORE_ERRORS show that transactions continue (due
to explicit savepoints inserted by the driver) even in the face of
errors. Explicit
On Fri, 2006-06-02 at 20:12 +1000, Bojan Smojver wrote:
length:column:table:payload
-- -- - ---
^ ^ ^ ^
| | | +--- binary data, length in size
+--+--+- ascii
Obviously, for most databases column and table could
On Thu, 2006-06-01 at 10:06 +0100, Joe Orton wrote:
The MySQL stuff needs to be disabled by default (as it was previously?)
since the MySQL driver is not included in apr-util. Currently all
builds are failing on platforms with MySQL installed.
I just checked out 1.2.x of APR/APU and built
On Thu, 2006-06-01 at 11:18 +0100, Joe Orton wrote:
Did you try to link anything against that libaprutil? e.g. just try a
make -C test testall
Yeah, I see this now. I just built the thing and that worked. It appears
to be referring to undefined symbol apr_dbd_mysql_driver due to:
#if
On Thu, 2006-06-01 at 21:04 +1000, Bojan Smojver wrote:
Working on it...
Should be in trunk and 1.2.x now. Let me know if it worked for you too.
--
Bojan
On Thu, 2006-06-01 at 12:37 +0100, Joe Orton wrote:
Works fine now, thanks a lot for sorting this out.
No worries.
--
Bojan
On Thu, 2006-06-01 at 07:27 -0700, Rick Keiner wrote:
What's the status of the API change? This would bump the rev to 1.3,
correct? Any idea what the time frame is on this?
I got a bit sidetracked with the MySQL driver stuff, but I'm testing the
patch in my setup. I'm planning to test the whole
Quoting Bojan Smojver [EMAIL PROTECTED]:
I'm sure there are many more combos that we can consider, but these
should be a decent start.
One more note here: if we go with this approach, this is almost
certainly something for APU 2.0 due to existing implementation
incompatibility
Quoting Alex Dubov [EMAIL PROTECTED]:
I'm actually ok with this. But why do you need 4 blob
types? I say - give backend a bucket and it should
figure by itself what to do with it (use smallest blob
type available that fits). I would also propose a
plain bucket type, to simplify things:
%b -
Quoting Chris Darroch [EMAIL PROTECTED]:
You have to do the insert with an empty CLOB placeholder, then
retrieve the ID for the newly inserted row, perform a SELECT ...
FOR UPDATE statement on that row ID, retrieve the OCILobLocator* for
the CLOB from the output parameters, and finally
Quoting Alex Dubov [EMAIL PROTECTED]:
Second, instead of paying attention to various
letters like %B, %L, %s
and so on, which come from when the statement was
prepared, we ignore
them in p[v]bquery/bselect, but we pass
apr_dbd_entry_t ** instead of
const char ** into the function. Then we have
On Mon, 2006-05-29 at 00:21 -0700, Alex Dubov wrote:
I don't like it
because it requires two allocations (one for struct
and other for data).
The *data[] was a typo, actually... I just wanted the size to be APR
size, the rest is good.
--
Bojan
On Mon, 2006-05-29 at 11:24 +0100, Nick Kew wrote:
The Oracle driver uses uppercase; %C for CLOB and %B for BLOB,
%L for LOB (hey, I can't even remember which of these are working
and which are placeholders!). Is there any reason not to follow that
convention for other drivers implementing
On Sun, 2006-05-28 at 18:55 -0700, Alex Dubov wrote:
Yes, it was a reason why I started to play with
apr_dbd_mysql. I'm using a lot of binary data and I
must use 'pascal' style strings to do this (so there
is distinction between '%s' and '%c').
I understand. However, this API is primarily a C
Just going through the bind arguments portion of the patch. In the new
code, %s expects BLOB - is this intentional? I would think more people
would intuitively think of %s as a zero terminated string...
--
Bojan
Quoting Alex Dubov [EMAIL PROTECTED]:
The comment also says that it is possible to do
something like this for mysql 5.0.13:
-
MYSQL *db;
db = mysql_real_connect(db, ...)
db-reconnect = 1;
...
-
Right. I don't think we need to worry about these old versions anyway,
given that
On Tue, 2006-05-23 at 23:44 -0700, Alex Dubov wrote:
mysqlclient's heap will
slowly grow because of all these temporary MYSQL
objects never being reclaimed.
You're right. I misread the description in the MySQL manual.
--
Bojan
In r39. Thanks for your patch!
--
Bojan
Quoting Henry Jen [EMAIL PROTECTED]:
Another attempt with checking result of palloc/pcalloc(thanks Davi
pointing those out).
I'm getting more and more confused with the allocator error checking...
I thought there was no point in handling allocation errors (coming
from our own allocator) in
Error reporting should now be in, with some style tweaks. I also made
sure it compiles under 4.1. See r40 of the driver.
--
Bojan
On Mon, 2006-05-22 at 11:12 +0100, Joe Orton wrote:
Hi Bojan - some comments on the autoconf code:
Here is a patch that hopefully deals with the issues you mentioned in
the new code, as well as the stuff that was already in dbd.m4. I tested
this on FC5 (i386) and it seems to work for PostgreSQL,
On Tue, 2006-05-23 at 13:51 +0100, Joe Orton wrote:
- APR_ADDTO(APRUTIL_INCLUDES, [-I$withval/include/postgresql])
+ APR_ADDTO(APRUTIL_INCLUDES, [-I/usr/include/postgresql])
This also isn't really correct; it presumes that the *only* include path
is /usr/include which
Quoting Alex Dubov [EMAIL PROTECTED]:
libmysqlclient v4 reconnects automatically when mysqld
closes connection. libmysqlclient v5 won't. I thought
to implement explicit reconnect for this condition,
but then found that it can be easily enabled in mysql
= 5.0.13.
Committed to to Nick's SVN.
Quoting Alex Dubov [EMAIL PROTECTED]:
libmysqlclient v4 reconnects automatically when mysqld
closes connection. libmysqlclient v5 won't. I thought
to implement explicit reconnect for this condition,
but then found that it can be easily enabled in mysql
In your testing, does 3rd comment on
On Sun, 2006-05-21 at 23:49 -0700, Alex Dubov wrote:
won't it be better to add max_field_size= key to the
dbd parameter string (with some sane default and 0
defined as unlimited)?
Yep, we can do that.
--
Bojan
On Mon, 2006-05-22 at 11:12 +0100, Joe Orton wrote:
With AC_PATH_PROG the program name should be in capitals by convention;
AC_PATH_PROG(MYSQL_CONFIG, ...)
OK.
You should never overwrite CPPFLAGS/LDFLAGS like this; use:
mysql_CPPFLAGS=`...`
mysql_LDFLAGS=`...`
On Mon, 2006-05-22 at 21:22 -0300, Davi Arnaut wrote:
Be concise, either check all apr_pcalloc failures or none.
I'm still confused about this. Shouldn't we just let things segfault if
the allocator is out of memory? I thought that was the APR way...
--
Bojan
I tested this on Fedora Core 5 and RHEL4 (both x86_64) and it appeared
to work fine with packaged version of MySQL 5.0 and 4.1. However,
environments vary wildly, so it it would be good to get some feedback
before going ahead with the commit.
I'm a little bit worried that --libs_r may put
Sorry abuot those $$ in the previous patch. Not sure how that got in... :-(
--
Bojan
Index: build/dbd.m4
===
--- build/dbd.m4 (revision 408512)
+++ build/dbd.m4 (working copy)
@@ -77,24 +77,40 @@
], [
apu_have_mysql=0
Quoting Alex Dubov [EMAIL PROTECTED]:
Ok. Here is a patch against webthing's rev 34 (I
assume it's a last one).
Yep, that's right.
There's a brief changelog in
the beginning of the file.
Two warnings, however:
1. I only use mysql-5
I think Nick wanted to see the driver working with 4.1
701 - 800 of 930 matches
Mail list logo
