On Fri, May 16, 2008 at 01:34:29PM +1000, Bojan Smojver wrote:
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
On Thu, May 15, 2008 at 6:39 PM, Graham Leggett [EMAIL PROTECTED] wrote:
Wrapping the LDAP library however does make things cleaner, and does empower
us to create standard behaviour should a future LDAP library come along and
act funny. So if you want to wrap all the LDAP functions for v2.0, I
I am assuming that this is NOT with the latest apr-1.3 HEAD
code. Can you confirm that with the latest, all is well?
I believe this is the only outstanding issue with apr?-1.3,
meaning that we can hopefully release APR and then httpd
(I don't want to delay httpd, but it is waiting for either
1.3
On May 14, 2008, at 7:33 PM, Jim Jagielski wrote:
I'll have to try that... in the meantime, does re-adding
the 'rv=0' line fix it?
For me - yes !
Dw.
Eric Covener wrote:
+1 on wrapping it all in 2.0, but I don't think the versioning
restrictions allow apr-util to stop linking against LDAP in 1.3 -- for
example applications that load ldap symbols privately (not at all
shouldn't be an issue because they can't do anything useful with the
Jim Jagielski wrote:
I am assuming that this is NOT with the latest apr-1.3 HEAD
code. Can you confirm that with the latest, all is well?
Right - these issues were pre-patch. Once you applied r656722,
all is well now.
Based on Roy's legitimately rabid reaction to the cruft that blows
into
On May 16, 2008, at 10:43 AM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
I am assuming that this is NOT with the latest apr-1.3 HEAD
code. Can you confirm that with the latest, all is well?
Right - these issues were pre-patch. Once you applied r656722,
all is well now.
woot!
Hi,
I'm looking at dbd_pgsql_open. I noticed the comment,
/* if there's an error in the connect string or something we get
* back a * bogus connection object, and things like PQreset are
* liable to segfault, so just close it out now. it would be nice
* if we could give an
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 Sat, May 17, 2008 at 08:28:33AM +1000, Bojan Smojver wrote:
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
Wow! Great! I already have this
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 Sat, May 17, 2008 at 10:23:59AM +1000, Bojan Smojver wrote:
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:
Bob Rossi wrote:
Yes, that worked! I suggest putting a comment in the patch that says
that crypt must be done before postgresql, otherwise it will fail to
test link.
Actually that's half-assed. We have to back out the changes that the DBD
detection causes for LDFLAGS and LIBS, etc, in
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
Bojan Smojver wrote:
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? ;-)
No but since you did, my +1.
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
Hi,
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,
#ifndef APU_DSO_BUILD
/* Load
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,
22 matches
Mail list logo
