On Fri, 2008-06-20 at 11:02 -0600, Steve Comstock wrote:
configure:3817: checking for C compiler default output file name
configure:3839: ccconftest.c 5
CCN0634(U) Unable to load CCNETBY
FSUM3065 The COMPILE step ended with return code 64.
FSUM3017 Could not compile conftest.c. Correct
On Thu, 2008-06-19 at 21:07 -0600, Steve Comstock wrote:
checking for APR... reconfig
configuring package in srclib/apr now
trap: /Z19/usr/lpp/zApache/httpd-2.2.9/srclib/apr/configure 2047: FSUM7327
signal number 13 not conventional
[Can someone explain to me what's going on,
On Wed, 2008-06-18 at 12:10 +0100, Nick Kew wrote:
Hmmm. handle-handle appears already void* in arch/unix/apr_arch_dso.h.
However, handle-handle, which is actually used here, is (void **),
hence the warning.
Just wondering if shl_t should be apr_os_dso_handle_t, and if so
whether the latter
I didn't mention this before, but with this change, the DSO test passes
on HP-UX.
--
Bojan
I'm getting these on Fedora 9, x86_64:
---
dbd/apr_dbd_odbc.c: In function ‘odbc_open’:
dbd/apr_dbd_odbc.c:1010: warning: cast to pointer from integer of
different size
dbd/apr_dbd_odbc.c: In function ‘odbc_start_transaction’:
dbd/apr_dbd_odbc.c:1101: warning: cast to pointer
On Tue, 2008-06-17 at 08:40 -0500, William A. Rowe, Jr. wrote:
+/-1
[+1] Release apr 1.3.2 as GA
[+1] Release apr-util 1.3.2 as GA
Good MD5s. Good signatures.
Fedora 9, i686/x86_64.
CentOS 5, i686/x86_64.
RHEL 4, i686.
CentOS 3, i686.
--
Bojan
This time on HP-UX. The attached patch avoids it. Please review.
--
Bojan
Index: dso/unix/dso.c
===
--- dso/unix/dso.c (revision 668877)
+++ dso/unix/dso.c (working copy)
@@ -178,9 +178,9 @@
int status;
errno = 0;
-
On Tue, 2008-06-17 at 22:02 -0400, Tom Donovan wrote:
The Microsoft ODBC docs at
http://msdn.microsoft.com/en-us/library/ms713605(VS.85).aspx say:
SQLPOINTER ValuePtr
[Input] Pointer to the value to be associated with Attribute. Depending on
the value of
Attribute,
Also, HP-UX 11.11, PA-RISC, in 32-bit mode, APR, compiled with GCC:
Failed TestsTotal FailFailed %
===
testatomic 19 1 5.26%
testprocmutex 4 1 25.00%
testsockets 7
On Mon, 2008-06-16 at 22:09 +0200, Ruediger Pluem wrote:
I checked it on Red Hat AS 3 and it basicly works, but the 'two argument'
function prototype is wrong. I adjusted your patch accordingly and now
it compiles fine without any warning on Solaris 8, 9, 10 (SPARC, 32BIT)
and RHEL3 32 Bit
On Mon, 2008-06-16 at 22:20 +0200, Ruediger Pluem wrote:
struct servent *tmp = getservbyname_r((const char *) 0, (const char *) 0,
OUCH!
2. The repeated call to AC_CACHE_CHECK leads to multiple output lines in the
case that one of the previous tests fails.
Yeah, that was my
On Mon, 2008-06-16 at 23:21 +0200, Ruediger Pluem wrote:
Maybe the docs are wrong :-). I took it from the header file.
Yeah - much better idea.
--
Bojan
On Tue, 2008-06-17 at 00:22 +0200, Graham Leggett wrote:
The code quoted is line 279 of dbd/apr_dbd.c.
Do you also have the full backtrace (i.e. how we got to line 279 of
dbd/apr_dbd.c)?
--
Bojan
On Mon, 2008-06-16 at 20:05 +0200, Graham Leggett wrote:
Seems driver is NULL. Does this ring any bells for anyone?
Can you try this?
--
Bojan
Index: dbd/apr_dbd.c
===
--- dbd/apr_dbd.c (revision 668320)
+++ dbd/apr_dbd.c
On Tue, 2008-06-17 at 01:16 +0200, Graham Leggett wrote:
#0 apr_dbd_name (driver=0x8792990) at dbd/apr_dbd.c:279
If you do 'p *driver' here, what do you get?
--
Bojan
On Mon, 2008-06-16 at 18:50 -0500, William A. Rowe, Jr. wrote:
FYI - feel welcome to add the appropriate stuff to CHANGES please,
I had wasted a good four hours comparing 1.3 to trunk and noting
the gist of the changes to apr-1.3 because CHANGES had been ignored :)
Aren't these just bugfixes?
On Mon, 2008-06-16 at 18:49 -0500, William A. Rowe, Jr. wrote:
I see no other obstacles to retagging 1.3.2 and I will in about an hour
and a half unless someone hollers.
Ah, sorry. Didn't see you already planned to hold off for an hour and a
half. Hopefully, Graham can tell us before then...
On Tue, 2008-06-17 at 02:25 +0200, Graham Leggett wrote:
Success! The patch worked, and the test passed.
WOW - that was lucky. Thanks for testing!
--
Bojan
On Sun, 2008-06-15 at 13:08 +0200, Ruediger Pluem wrote:
The culprit seems to be the changes to build/apr in apr_network.m4
http://svn.apache.org/viewvc?view=revrevision=662607
APR_TRY_COMPILE_NO_WARNING is called nested again which causes the CFLAGS
restore to fail and to add -Werror
On Sun, 2008-06-15 at 14:43 +0200, Ruediger Pluem wrote:
The attached patch fixes this for me, but as I am no autoconf specialist
some remote eyes seem to be a good idea before committing.
Or we can just remember CFLAGS and restore them.
--
Bojan
Index: build/apr_network.m4
On Sun, 2008-06-15 at 12:39 -0500, William A. Rowe, Jr. wrote:
Do you know offhand that multiple AC_CACHE_VAL( ac_cv_val, ...) entries
are legit? Provided they are, your patch appears to handle all of the
nesting without introducing other duplications!
The AC_CACHE_VAL should be changed to
On Mon, 2008-06-16 at 08:02 +1000, Bojan Smojver wrote:
The AC_CACHE_VAL should be changed to AC_CACHE_CHECK, which then
provides pretty printing of messages for non-nested version of checks.
Could you check if this works on Solaris?
--
Bojan
Index: build/apr_network.m4
On Sun, 2008-06-15 at 13:08 +0200, Ruediger Pluem wrote:
Another issue I have mentioned before:
APR-UTIL fails to compile on Red Hat AS 3 with ldap turned on as the OpenLDAP
API seems to have changed between 2.0.x and 2.2.x:
ldap/apr_ldap_rebind.c: In function
On Mon, 2008-06-16 at 09:52 +1000, Bojan Smojver wrote:
Does this help?
Sorry, other LDAP toolkits may complain. This should be slightly better.
--
Bojan
Index: ldap/apr_ldap_rebind.c
===
--- ldap/apr_ldap_rebind.c (revision
On Mon, 2008-06-16 at 09:56 +1000, Bojan Smojver wrote:
Sorry, other LDAP toolkits may complain. This should be slightly better.
Nah, forget it - wrong and incomplete. Let me do a better one...
--
Bojan
On Mon, 2008-06-16 at 10:07 +1000, Bojan Smojver wrote:
Nah, forget it - wrong and incomplete. Let me do a better one...
OK, for real this time :-)
PS. I don't have RHEL3 platform handy, so please compile and let me
know.
--
Bojan
Index: ldap/apr_ldap_rebind.c
On Sun, 2008-06-15 at 19:53 -0500, William A. Rowe, Jr. wrote:
I'm pretty certain that duplicate AC_CACHE_CHECK(ac_cv_getservbyname_r_style
entries is an error.
Even with 'unset ac_cv_getservbyname_r_style'?
--
Bojan
On Mon, 2008-06-16 at 11:02 +1000, Bojan Smojver wrote:
Even with 'unset ac_cv_getservbyname_r_style'?
If I change the order of tests and make glibc2 last, it still gets
detected just fine, even after Solaris and OSF/1 failure, suggesting it
should work.
--
Bojan
On Mon, 2008-06-16 at 06:35 +0300, Lucian Adrian Grijincu wrote:
I only got some warnings at apr-util's ./buildconf:
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader:
On Sat, 2008-06-14 at 21:24 -0500, William A. Rowe, Jr. wrote:
and based on raw gnu packages, not fedora's idea of a good schema.
Hit this one in our config...
configure.in:144: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:385:
On Fri, 2008-06-13 at 03:33 -0500, William A. Rowe, Jr. wrote:
If someone on unix with all three providers can confirm this is clean,
I'm happy to backport.
It's clean.
--
Bojan
On Fri, 2008-06-13 at 02:15 -0500, William A. Rowe, Jr. wrote:
But this is a great fix (below) - care to backport to branches/1.3.x ?
Done in r667437.
--
Bojan
On Fri, 2008-06-13 at 03:33 -0500, William A. Rowe, Jr. wrote:
If someone on unix with all three providers can confirm this is clean,
I'm happy to backport.
Done in r667456.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
Honestly, I loathe tabs as much as the next guy, but I actually
dislike the idea of wholesale reformatting because it makes it harder
to figure out where a bit of code came from.
Exactly.
It's just a pain. I much more prefer reformatting to meet
On Thu, 2008-06-12 at 12:09 -0500, William A. Rowe, Jr. wrote:
we've found lots of nice small fixes to several platforms, and it would seem
good to release a 1.3.1 bugfix update fairly promptly. Here are some options
[X] tag it friday (13th)
[ ] tag it next wednesday (18th)
[ ] tag
On Thu, 2008-06-12 at 17:54 +, [EMAIL PROTECTED] wrote:
+SQL_C_CHAR, /*SQL_C_TYPE_TIME, /* APR_DBD_TYPE_TIME, \%pDi */
+SQL_C_CHAR, /*SQL_C_TYPE_DATE, /* APR_DBD_TYPE_DATE, \%pDd */
+SQL_C_CHAR, /*SQL_C_TYPE_TIMESTAMP, /* APR_DBD_TYPE_DATETIME, \%pDa */
On Thu, 2008-06-12 at 19:17 -0500, William A. Rowe, Jr. wrote:
This is looking great, do we feel it's ready for people to try out with
apr 1.3.1?
I have no idea if it actually works (it does compile and link). But hey
- that's how we'll find out :-)
--
Bojan
On Fri, 2008-06-13 at 10:26 +1000, Bojan Smojver wrote:
I have no idea if it actually works (it does compile and link).
It would be good if Windows folks could check this change that I made:
--
#ifdef HAVE_SQL_H
#include sql.h
#include sqlext.h
#elif defined(HAVE_ODBC_SQL_H
On Thu, 2008-06-12 at 20:27 -0400, Tom Donovan wrote:
I would be happy to take the /*'s out if it's confusing.
I already took them out.
Is there a reason not to have /* in a comment? They don't nest in C (but,
curiously - they're
suppose to nest in SQL - although few dbs actually do
On Thu, 2008-06-12 at 21:14 -0400, Tom Donovan wrote:
All set on Windows now - r667309
Thanks!
--
Bojan
On Thu, 2008-06-12 at 19:17 -0500, William A. Rowe, Jr. wrote:
This is looking great, do we feel it's ready for people to try out with
apr 1.3.1?
Tom,
Do you have an opinion on this?
PS. I would personally prefer to see ODBC DBC in 1.3.1.
--
Bojan
On Thu, 2008-06-12 at 23:14 -0400, Tom Donovan wrote:
I changed APU_DECLARE_DATA to APU_MODULE_DECLARE_DATA when I checked it into
apr (copying the mysql
driver). Am I missing something?
Sadly, nothing. The whole build thing is busted - even for FreeTDS
driver. I'm fixing now.
--
Bojan
On Fri, 2008-06-13 at 04:10 +, [EMAIL PROTECTED] wrote:
@@ -646,7 +649,7 @@
if (SQL_SUCCEEDED(rc) || rc == SQL_NO_DATA) {
-if (rc = SQL_SUCCESS_WITH_INFO
+if (rc == SQL_SUCCESS_WITH_INFO
( len_indicator == SQL_NO_TOTAL || len_indicator = bufsize)
On Fri, 2008-06-13 at 00:32 -0400, Tom Donovan wrote:
The second one doesn't change the behavior, just cleaning up -Wall
warnings, right?
That's right. Thanks for reviewing.
If nobody objects, I'm going to backport ODBC driver to 1.3.x then.
--
Bojan
On Wed, 2008-06-04 at 06:58 +, [EMAIL PROTECTED] wrote:
Author: bojan
Date: Tue Jun 3 23:58:15 2008
New Revision: 663011
URL: http://svn.apache.org/viewvc?rev=663011view=rev
Log:
Update docs for 1.3.
Update docs for trunk.
I left 1.2 docs in place for now, just in case someone
On Wed, 2008-06-04 at 18:28 -0500, William A. Rowe, Jr. wrote:
Many linkage problems, but it compiles now. I'll work those out.
OK, thanks.
I'm not sure what to do about that FreeTDS thing. We use/ship PCRE
within Apache, but we don't have support for that in APR/APU. Were you
hinting at
On Mon, 2008-06-02 at 20:10 -0500, William A. Rowe, Jr. wrote:
apr_dbd_mysql.c(142) : warning C4244: 'function' : conversion from '__int64
' to 'unsigned long ', possible loss of data
apr_dbd_mysql.c(256) : warning C4018: '=' : signed/unsigned mismatch
apr_dbd_mysql.c(416) : warning C4244:
How does this patch work for you? I don't have Windows so I cannot
test...
--
Bojan
Index: dbd/apr_dbd_mysql.c
===
--- dbd/apr_dbd_mysql.c (revision 662610)
+++ dbd/apr_dbd_mysql.c (working copy)
@@ -139,7 +139,8 @@
/* fetch
On Mon, 2008-06-02 at 19:31 +, [EMAIL PROTECTED] wrote:
Backports: r662529
Does that mean you're planning on spinning 1.3.1?
--
Bojan
On Mon, 2008-06-02 at 17:37 -0500, William A. Rowe, Jr. wrote:
Not unless -1's appear.
OK, thanks. I was asking because there were a few commits to trunk that
would be worth backporting in case you were re-spinning. Unless people
object, I will do that soon, so that I don't forget before 1.3.1.
On Mon, 2008-06-02 at 18:50 -0500, William A. Rowe, Jr. wrote:
Please feel free! Such things are easily forgotten later on.
OK.
That patch is fine. And yes - it's worth debating how to communicate
the notice information from the engines (first question; how do these
correspond to other
On Mon, 2008-06-02 at 20:07 -0500, William A. Rowe, Jr. wrote:
and I'm looking for one answer; are we inhibited from shipping the
apr_dbd_xxx-1.dll binary for oracle, pgsql or sqlite3? If so I'll
adjust before uploading any binaries.
PosgreSQL is licensed under a BSD licence, so we are fine
On Mon, 2008-06-02 at 21:17 -0500, William A. Rowe, Jr. wrote:
In any case, there is nothing stopping us from shipping these three driver
connectors that I can find. Thoughts or comments?
Given that this is a Windows specific, I have no idea (just so you know
I'm not ignoring your question).
Better fix?
--
Bojan
Index: include/apr_ring.h
===
--- include/apr_ring.h (revision 662145)
+++ include/apr_ring.h (working copy)
@@ -157,7 +157,7 @@
* @param link The name of the APR_RING_ENTRY in the element struct
*/
#define
And just a note that we still get these:
-
poll/unix/epoll.c: In function 'apr_pollset_add':
poll/unix/epoll.c:184: warning: dereferencing type-punned pointer will
break strict-aliasing rules
poll/unix/epoll.c:184: warning: dereferencing type-punned pointer will
break
On Sun, 2008-06-01 at 00:50 +, [EMAIL PROTECTED] wrote:
Supplementary to r661146:
- Include the necessary unistd.h
Doesn't this do it for you?
http://svn.apache.org/viewvc/apr/apr/trunk/include/arch/unix/apr_arch_shm.h?r1=428317r2=661146
--
Bojan
On Sat, 2008-05-31 at 23:49 +0100, Nick Kew wrote:
Needs an additional #include unistd.h. Without that, it gives compile
warnings on Linux (access() undeclared) and errors out on solaris
(neither access() nor F_OK declared).
On Sat, 2008-05-31 at 17:36 +1000, Bojan Smojver wrote:
And just a note that we still get these:
-
poll/unix/epoll.c: In function 'apr_pollset_add':
poll/unix/epoll.c:184: warning: dereferencing type-punned pointer will
break strict-aliasing rules
This patch avoids
On Sun, 2008-06-01 at 13:43 +1000, Bojan Smojver wrote:
This patch avoids the warning for me. Not sure if it makes any sense at
all...
Actually, there is no need for that (char *) cast.
--
Bojan
Index: include/apr_ring.h
On Sun, 2008-06-01 at 01:38 +, Nick Kew wrote:
Probably. But I hadn't seen that when I applied the patch shown to 1.3.
Sorry, I should have pointed here:
http://svn.apache.org/viewvc?view=revrevision=661146
And I'm not testing now: it's 2:39 a.m. here!
No kidding :-)
--
Bojan
On Fri, 2008-05-30 at 01:50 -0500, William A. Rowe, Jr. wrote:
So if it's possible with the postgresql to mute the stdout information,
we really need to do so.
I'm not convinced of the usefulness of this, but here is the patch
nevertheless.
--
Bojan
Index: dbd/apr_dbd_pgsql.c
On Fri, 2008-05-30 at 12:00 +0100, Nick Kew wrote:
Wouldn't a better patch be to save the message internally so that
a subsequent dbd_pgsql_error picks it up?
AFAICT, this doesn't affect errors, just warnings and notices:
http://www.postgresql.org/docs/8.3/static/libpq-notice-processing.html
On Fri, 2008-05-30 at 14:32 +0100, Nick Kew wrote:
Now therein lies a good idea: we could set that at startup, and perhaps
provide an option in a connection string or environment to override it.
Does PQconnectdb provide any such option?
Given that 1.3.0 has been tagged, this is now 2.x
On Fri, 2008-05-30 at 17:26 -0500, William A. Rowe, Jr. wrote:
Unix tarballs are up, win32 .zip's with .mak files will follow.
Your votes please;
+/-1
[+1] Release apr-1.3.0 as GA
[+1] Release apr-util-1.3.0 as GA
Fedora 9, i686/x86_64, RHEL 5 i686/x86_64, APR:
On Fri, 2008-05-30 at 21:03 -0500, William A. Rowe, Jr. wrote:
But I agree that is not a showstopper, and it's still better off than when
we were limited to make install; make test.
Absolutely and nice work.
--
Bojan
On Thu, 2008-05-29 at 21:15 -0400, Bob Rossi wrote:
One issue I've noticed with postgresql is that when you use it through
apr, and postgresql detects an error, it prints to stdout.
Do you think that apr should catch this, or do you think that my
application should get the handle, and catch
On Wed, 2008-05-28 at 14:57 -0500, William A. Rowe, Jr. wrote:
but give a ping anyways
Any opinion on these two:
http://www.mail-archive.com/dev@apr.apache.org/msg20226.html
http://www.mail-archive.com/dev@apr.apache.org/msg20223.html
--
Bojan
On Wed, 2008-05-28 at 16:40 -0500, William A. Rowe, Jr. wrote:
Neither is an API-changing showstopper. If anyone has free cycles to
jump on them, great. Otherwise, in another release or so.
OK.
--
Bojan
On Wed, 2008-05-28 at 22:52 +, [EMAIL PROTECTED] wrote:
As 1.3 rolls, it's the end of this line. Also fix a notable
absense of data.
So, no more backports to 1.2.x, right?
--
Bojan
On Thu, 2008-05-29 at 01:57 +, [EMAIL PROTECTED] wrote:
Fix PR44367.
Obviously, relying on CTR here.
Caveats:
- no idea if IBM's proprietary OSes actually have thread-safe
version of getservbyname() function, just assumed that by looking at
other similar functions being marked safe
On Tue, 2008-05-27 at 15:08 -0400, Aaron Wiebe wrote:
#define _LARGEFILE64_SOURCE
You sure you want to do this in your source? Try picking up these things
from apr-1-config --cppflags. Setting things like this explicitly may
change sizes of structures inside APR headers causing overflows.
--
On Tue, 2008-05-27 at 16:36 +1000, Bojan Smojver wrote:
Before I get into researching this issue
(https://issues.apache.org/bugzilla/show_bug.cgi?id=44367), does anyone
know off the top of their heads if getservbyaddr() is now thread safe on
all platforms that we support?
For instance
On Wed, 2008-05-28 at 09:45 +1000, Bojan Smojver wrote:
So, given that we have at least one OS that would for sure require use
of thread safe functions, I think this should be fixed.
For instance, something like the attached.
Caveats:
- I have no idea if IBM's proprietary OSes actually have
On Wed, 2008-05-28 at 11:20 +1000, Bojan Smojver wrote:
For instance, something like the attached.
Don't you just hate it when you have to do this?
--
Bojan
Index: network_io/unix/sockaddr.c
===
--- network_io/unix/sockaddr.c
Just ran make check against trunk/1.3.x and got this:
./testall -v testshm
testshm : -Line 254: Error destroying shared memory block
(2): No such file or directory
FAILED 1 of 6
Failed TestsTotal FailFailed
On Wed, 2008-05-28 at 14:12 +1000, Bojan Smojver wrote:
Maybe shm_cleanup_onwer() should check (line 73 of shmem/unix/shm.c) to
see if the the file has already been removed and return APR_SUCCESS if
it was, instead of always calling apr_file_remove()?
Something like this (possibly required
On Wed, 2008-05-28 at 14:29 +1000, Bojan Smojver wrote:
Something like this (possibly required in other places too).
Sorry, forgot to modify the header file. BTW, this patch makes it pass
the tests.
PS. Obviously, similar things may need to be applied to other places in
the same function
On Fri, 2008-05-23 at 13:12 +0100, Joe Orton wrote:
Interesting - is that gcc 4.3?
Yep, Fedora 9.
The code is bogus because it assumes all
the expansions of the macro result in a string with the same address;
does this patch fix the warning?
Yes, it does.
--
Bojan
On Thu, 2008-05-22 at 22:37 +, [EMAIL PROTECTED] wrote:
Modified: apr/apr-util/trunk/build/dbd.m4
URL:
http://svn.apache.org/viewvc/apr/apr-util/trunk/build/dbd.m4?rev=659293r1=659292r2=659293view=diff
==
---
On Wed, 2008-05-21 at 07:50 +1000, Bojan Smojver wrote:
I'm getting this (APR 1.2.x):
-
strings/apr_snprintf.c: In function 'apr_vformatter':
strings/apr_snprintf.c:1253: warning: comparison with string literal
results in unspecified behavior
On Thu, 2008-05-22 at 20:23 -0500, William A. Rowe, Jr. wrote:
I'll pull this as part of the dbm separation, as a matter of fact I already
had a build/dso.m4 in the tree here :)
Cool.
--
Bojan
On Thu, 2008-05-22 at 17:52 -0500, William A. Rowe, Jr. wrote:
Please, review. Thanks.
Gettin' these:
misc/apu_dso.c: In function 'apu_dso_init':
misc/apu_dso.c:84: warning: suggest parentheses around assignment used
as truth value
On Thu, 2008-05-22 at 22:06 -0500, William A. Rowe, Jr. wrote:
Can you recheck from the branch? should have been fixed in r659343
Check. All is well :-)
--
Bojan
On Wed, 2008-05-21 at 10:13 -0400, Bob Rossi wrote:
OK, I have confirmed 1 bug. If you pass '0' to apr_dbd_get_row, with
postgresql as the driver, the function returns 0, instead of -1 as it
should. My unit tests happen to test the cases that should fail, that's
how I caught this.
Try now. I
On Wed, 2008-05-21 at 07:43 -0500, William A. Rowe, Jr. wrote:
IMHO this is a user-facing change and demands an explicit statement in
the CHANGES file, eh? Was also staring this morning at the testdbd output
which reports results in a 0-based row list, perhaps that should change
so we don't
On Wed, 2008-05-21 at 16:29 -0400, Bob Rossi wrote:
Ok, all my unit tests pass on linux and windows. Thanks a million!
You are welcome. Thank you for testing!
--
Bojan
On Wed, 2008-05-21 at 17:59 -0500, William A. Rowe, Jr. wrote:
Any thoughts? This is required before release to allow `make test` to work
before the dbd (ldap etc) providers are installed.
Sorry, breakfast :-)
Generally speaking, we should be looking at explicit paths, because we
want to
On Tue, 2008-05-20 at 06:55 -0400, Bob Rossi wrote:
OK, I can try this, however, this patch still doesn't work on windows. I
get link errors on windows because the the libs aren't linked in.
$ ./pg_config --libs
-lpgport -lm -lSecur32 -lws2_32 -lshfolder
$ ./pg_config --libdir
On Wed, 2008-05-21 at 06:59 +1000, Bojan Smojver wrote:
OK, not a problem. We'll whack libs in there too.
Done. Hopefully that should be it.
--
Bojan
I'm getting this (APR 1.2.x):
-
strings/apr_snprintf.c: In function 'apr_vformatter':
strings/apr_snprintf.c:1253: warning: comparison with string literal
results in unspecified behavior
-
The line is:
On Tue, 2008-05-20 at 19:34 -0400, Bob Rossi wrote:
--- apr-util-1.3.x-2008-05-19-svn/build/dbd.m4 Tue May 20 17:15:38 2008
+++ apr-util-1.3.x-2008-05-19-svn.changed/build/dbd.m4 Tue May 20 19:18:23
2008
@@ -53,7 +53,8 @@
AC_PATH_PROG([PGSQL_CONFIG],[pg_config],,[$withval/bin])
On Tue, 2008-05-20 at 20:04 -0400, Bob Rossi wrote:
I noticed you changed everything but the AC_CHECK_LIB, do you believe
that is unnecessary, or are you thinking about it?
Not required. We set LDFLAGS specifically for the test (hence the
APR_ADDTO(LDFLAGS, [$pgsql_LDFLAGS])) and then we
On Tue, 2008-05-20 at 20:26 -0400, Bob Rossi wrote:
That's because as you can see the -lpq went at the
end which is incorrect.
The real problem is that we're adding libraries to LDFLAGS. We should be
adding them to LIBS. I meant to fix that long time ago, but I always get
put off by the fact
On Tue, 2008-05-20 at 21:47 -0400, Bob Rossi wrote:
That worked on windows! I don't have time to test linux now.
Thanks for testing. It works on Linux.
--
Bojan
On Mon, 2008-05-19 at 15:54 -0400, Bob Rossi wrote:
So basically I need -lSecur32 and ws2_32. What can I do about this?
I don't have any Windows machines (nor development tools), so I cannot
do this. I'm sure someone else on the list that does will pick this up.
Sorry...
--
Bojan
On Mon, 2008-05-19 at 16:07 -0400, Bob Rossi wrote:
You know, I really think you should be using the --libs there. What
could the downside be? It's not like you need to add all the --libs to
the apr libs. It's just setup temporarily to get the -lpq to link.
This returns libraries that were
On Mon, 2008-05-19 at 16:33 -0400, Tom Donovan wrote:
It appears to be a presumption that only one dbd provider is used in an
application. A private
per-provider lock seems like a much better idea for dbd drivers which use it
like SQLite Oracle do.
Actually, in my apps I use all drivers,
On Mon, 2008-05-19 at 15:56 -0500, William A. Rowe, Jr. wrote:
Then if we consider this non-portable, the prepared statement cache
certainly should not be a static, but scoped per apr_dbd_t?
I would prefer we /not/ offer dbd specific features, as the hacks around
the initial row offset
On Mon, 2008-05-19 at 16:22 -0500, William A. Rowe, Jr. wrote:
Well I'd rather it include more libraries than needed (which are not bound
on more sophisticated linkers) than an insufficient number.
OK, I'll do --libs then.
--
Bojan
On Mon, 2008-05-19 at 17:37 -0500, William A. Rowe, Jr. wrote:
yes; my question is, even if we do construct a cache, is module lifetime
appropriate? When accessed by several different consumers at once? (e.g.
two libraries that rely on dbd, or several different httpd modules and
401 - 500 of 930 matches
Mail list logo
