Hmm...this didn't seem to make it to the newsgroup. Apologies if its a
repeat.
Charlie
-
Hi everyone,
I've been able to successfully build server extension using Visual
Studio 2005 for Windows Postgresql 8.1. However, it took a few tweaks
which I thought I should document (maybe
Postgresql itself, but
with VC++ instead of MinGW.
Charlie
Qingqing Zhou wrote:
"Charlie Savage" <[EMAIL PROTECTED]> wrote
I've been able to successfully build server extension using Visual
Studio 2005 for Windows Postgresql 8.1. However, it took a few tweaks
which I t
Hi everyone,
Thanks for the feedback. The reason for building extensions with MSVC
on windows is to get access to the Micrsoft debugging tools since as
far as I can see MingW/GDB cannot debug dynamically loaded dlls on the
Windows platform (or at least I haven't succeeded at doing it).
Anywa
I'm compiling postgresql 9.0.2 using msys + mingw + gcc 4.5.2 (latest
official release from mingw). This is on Windows 7 64-bit.
Unfortunately the built dlls, at least libpq.dll, crash if they need to
be relocated. This happens to me when loading libpq.dll into a project
that has a number of
In addition to the encoding issues I have with the 8.2.4 MSVC++ build
(see previous email), there are some other issues that I've run into:
1. The custom build step that generates DEF files for DLLS using a perl
script does not work. The perl script runs, and a slew of symbol
information is
Hope this is the right place for this post...
I'm been trying out the msvc++ build scripts for postgresql 8.2.4 on my
development laptop (using window xp pro).
I noticed the sort orders of queries changed. Investigating more,
encodings don't seem to be working as expected.
Using a MSVC++ b
Using a MSYS build:
> CREATE DATABASE test1 WITH ENCODING = 'utf8';
> show all
"lc_collate";"en_US.UTF-8"
"lc_ctype";"en_US.UTF-8"
"lc_messages";"C"
"lc_monetary";"C"
"lc_numeric";"C"
"lc_time";"C"
Sorry, the above output is for Linux (Fedora Core 6). With an MSYS
build on my XP laptop it
Hi Andrew,
Thank for the reply.
In both cases, the database clusters were created like this:
initdb ---locale=c --encoding=utf8;
That seems most unlikely - without the superfluous dash it should set
both lc_collate and lc_ctype to C.
Ah, sorry, that was a typo. If you actually try it:
Hi Magnus,
Yeah, this is a known problem, and it's fixed for 8.3. Really, the msvc
build process in 8.2 has a *lot* of rough edges ;-) The code itself builds
fine, but the buildsystem needed a lot more work.
Great - figured that might be the case.
3. If you have a contrib module that is no
Hi Korry,
Can you e-mail the VC++ projects that you created? (You can do that
off-list). I have VC++ here but I haven't tried to do a PG build in
that environment yet (guess it's time to learn).
Done.
However, I can't set any breakpoints using PgAdmin. I know the dlls
are loaded via Pro
Hi Korry,
I am having problems with getting the debugger to work. Setup:
OS: Windows XP
Postgresql Version: 8.2.4 compiled with VC++ 2005
Since my version of pg is built with VC++ I thought it wise to also use
VC++ for the debugger plugin. So I converted the Makefile into 3
different VC++ p
Oh, didn't realise you'd stick it in the actual contrib tree. I thought
it would build with pgxs or something.
You used to have to build postgis from the contrib directory. That
changed a while back, but I guess its just habit. It has its own
configure and makefile scripts, so doesn't seem t
A couple of months ago I noted that 8.3.4 doesn't compile on Vista using
MingW+msys under certain conditions:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01496.php
8.3.5 has the same problem.
Attached are two one line patches that fix it.
Thanks,
Charlie
--- libpq-int.h 2008-11-
Charlie Savage wrote:
A couple of months ago I noted that 8.3.4 doesn't compile on Vista using
MingW+msys under certain conditions:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01496.php
8.3.5 has the same problem.
Attached are two one line patches that fix it.
Sorry, I att
Just wanted to close off this thread.
Previously I reported that building 8.3.4 with MingW on Windows resulted
in an initdb executable that couldn't create new databases due to
security restrictions in creating global file mappings in Vista.
I'm happy to say that the problem seems fixed in 8.
Hi Bruce,
Uh, do we still need this patch?
I'd say yes for 8.3.x (my guess is that I see this because I have
additional libraries installed on my mingw version versus what other
developers have - perhaps openssl-0.9.8i).
Not sure on 8.4, but can test if you'd like.
Charlie
smime.p7s
Des
user running initdb built with VC++ works but
running initdb with MingW fails. Any help much appreciated...
Thanks,
Charlie
--
Charlie Savage
http://cfis.savagexi.com
smime.p7s
Description: S/MIME Cryptographic Signature
ql.org/cvsweb.cgi/pgsql/src/backend/port/win32_shmem.c?r1=1.4&r2=1.5
Specifically, you can reintroduce the old bug (that I think is hat made
it work on Vista) by removing the +18 in the lowest loop there.
Ok, I just reverted the whole patch (so all 4 changes), did a make clean
; make; mak
It's on my list to discuss it with Magnus when we meet in Italy
tomorrow. The simple fix is to back out the change that broke it,
which leaves us in our previous broken-but-less-severely state (which
is what we did for the binary packages).
If you mean reverting the patch that Mangus mentioned,
19 matches
Mail list logo
