On Wed, February 8, 2006 07:06, Bert Hinrichs wrote: > > I am building on windows xp, against the latest Cygwin and PostgreSQL > 8.1.2. > Something you may want to add to the FAQ is don't use WinZip to unpack the > tarballs without fixing the eol settings. > I would up using Cygwin's gunzip and tar.
Thanks for the tip... Could you describe exactly what those settings are? This is not a platform I have access to, so I'll have to go purely on your description. Also, I think most Windows users nowadays use MSYS rather than Cygwin, so that may be behind some of the problems you're seeing. Also, is "I would up" a typo? Are you saying people should use it, or not use it? > 2.6.2 failed to compile test087 (it is missing a sys/time.h include). That is odd--2.6.2 doesn't include sys/time.h anywhere, only the standard header "ctime" which in turn probably includes sys/time.h. Looks like there's something not quite right with your compiler environment. :-/ So what exactly did you do to fix that? > I fixed that, tests 0, 1, and 2 run, but test003 and test022 (I think) > hang. I get 100% cpu utilization, but they just sit there. I killed > test003 in Task Manager, then it went on running tests up to test022. That's quite a likely combination; test022 is derived from test003. It looks to me like the trace output is the problem. These two tests (and no other ones) enable trace output by calling their connections' trace() function, which does little more than turn on the equivalent option in libpq. Trace output dumps a lot of information about the communication between libpq and the server, to stdout in this case, so it's not very useful to most people. Again, this doesn't look like a problem in libpqxx itself so much as one with the underlying software--it may be a nasty interaction between Cygwin and libpq. Maybe stdout is somehow locked, causing the trace output to be held up waiting for it. The functionality that's breaking here is sufficiently obscure (and useless for any automated work) that it may not have been properly tested. Does the problem go away if you remove the respective lines reading C.trace(stdout); from these tests programs? > It does not matter what I set PGDATABASE or PGUSER to. It just takes my > username and wants to use that as the login and database name. It doesn't > appear to use any of the environment variables. Mayber this is a psql > problem, but, psql seems to work fine. This again is a problem that happens underneath libpqxx; libpq ought to pick up those variables and use them. Just to make sure, does psql respect those settings in *exactly* the same situation? I mean, you're not in a different shell or anything like that? And they were both built using the same compiler environment? > Are these known problems? Are there fixes or workarounds? I couldn't > find any reference to them in the general mailing list. I don't think these are known problems, no. Then again, I don't recall hearing from other Windows users who were building on Cygwin. I think these problems have something to do with that. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
