Some modifications are needed to compile libpq with vc6:
fe-connect.c:
- pg_config_paths.h isn't available. SYSCONFDIR is already defined so
fe-connect.c doesn't need to include that.
patch appended
win32.mak:
- pg_config.h must be generated
- port/pgstrcasecmp.c is needed
- port/path.c is not ne
I noticed that SYSCONFDIR will also be an issue for relocatable installs
just like localedir. I will address them in the same way either as an
environment variable or libpq function call to set the location.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://m
Bruce Momjian wrote:
>
> I noticed that SYSCONFDIR will also be an issue for relocatable installs
> just like localedir. I will address them in the same way either as an
> environment variable or libpq function call to set the location.
Fixed.
> >
> > fe-connect.c:
> > - pg_config_paths.h isn'
Bruce Momjian wrote:
fe-connect.c:
- pg_config_paths.h isn't available. SYSCONFDIR is already defined so
fe-connect.c doesn't need to include that.
patch appended
This shouldn't be needed anymore. Where is SYSCONFDIR coming from? Is
it from some Win32 include file? It should only be c
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >
> >
> >>>fe-connect.c:
> >>>- pg_config_paths.h isn't available. SYSCONFDIR is already defined so
> >>>fe-connect.c doesn't need to include that.
> >>>patch appended
> >>>
> >>>
> >
> >This shouldn't be needed anymore. Where is SYSCONFDIR
Bruce Momjian wrote:
Andreas Pflug wrote:
Bruce Momjian wrote:
fe-connect.c:
- pg_config_paths.h isn't available. SYSCONFDIR is already defined so
fe-connect.c doesn't need to include that.
patch appended
This shouldn't be needed anymore. Where is SYSCONFDIR comin
Andreas Pflug wrote:
The attached patch will create a dummy pg_config_paths.h.
Additionally, ENABLE_THREAD_SAFETY is supported by the makefile (but
not by the sources, which need some rework)
Now including the patch...
Regards,
Andreas
Index: win32.mak
===
Patch applied. I didn't realize that file was for win32 _client_
compiles, and I didn't realize it had no pg_config_paths.h.
---
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >Andreas Pflug wrote:
> >
> >
> >>Bruce Mom
The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled
with Visual C. Two additional files will supply the needed pthread stuff.
There's no SIGPIPE for native win32, so there are some #IFNDEF WIN32 to
skip installing a signal handler for this. I'm not sure if this is going
to sho
I have looked over this patch. I noticed this:
-static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
-
+static pthread_mutex_t init_mutex;
+static int mutex_initialized = 0;
+if (!mutex_initialized)
+
Bruce Momjian wrote:
I have looked over this patch. I noticed this:
-static pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
-
+static pthread_mutex_t init_mutex;
+static int mutex_initialized = 0;
+if (!mutex_initiali
Andreas Pflug wrote:
I don't really think so. That mutex_initialized is a globally static
variable, not a thread local one. Thread interruption between testing
mutex_initialized and setting it is very unlikely and still wouldn't
do much harm if it actually does happen.
Very unlikely is not a go
Manfred Spraul wrote:
> Andreas Pflug wrote:
>
> > I don't really think so. That mutex_initialized is a globally static
> > variable, not a thread local one. Thread interruption between testing
> > mutex_initialized and setting it is very unlikely and still wouldn't
> > do much harm if it actua
Bruce Momjian wrote:
Agreed. My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that. If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave the Unix safe.
Ok, so
Andreas Pflug wrote:
Bruce Momjian wrote:
Agreed. My pthread book says pthread_mutex_init() should be called only
once, and we have to guarantee that. If the Windows implentation allows
it to be called multiple times, just create a function to be called only
by Win32 that does that and leave the
Can you put that in the new pthread file that needs to be added for Win32?
---
Manfred Spraul wrote:
> Andreas Pflug wrote:
>
> > Bruce Momjian wrote:
> >
> >>
> >>
> >> Agreed. My pthread book says pthread_mutex_init() sh
Manfred Spraul wrote:
Wrong. There are portable test-and-set functions in the Win32 SDK: for
example InterlockedCompareExchange. They operate on ints and do not
need initialization.
'k, missed that one. Lets use it.
There is a third option: Add one C++ file and use the constructor to
initialize
Andreas Pflug wrote:
> Manfred Spraul wrote:
>
> >
> > Wrong. There are portable test-and-set functions in the Win32 SDK: for
> > example InterlockedCompareExchange. They operate on ints and do not
> > need initialization.
>
> 'k, missed that one. Lets use it.
>
> >
> > There is a third option
This patch has to be redone to make it thread-safe.
---
Andreas Pflug wrote:
> The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled
> with Visual C. Two additional files will supply the needed pthread stuf
Sorry, I accidentally bounced this to the lists.
The patch needs redesign and has been removed from the patch queue.
---
Andreas Pflug wrote:
> The appended patch implements ENABLE_THREAD_SAFETY for win32 compiled
> with V
Two minor tweaks:
in libpq-be.h isn't present on win32 vc6. Apparently, it
isn't used in Linux either; libpq will compile without it. All usages of
gettimeofday throughout the backend don't seem connection related, so
libpq-be.h seems an odd place to include it.
ERROR in elog.h has conflicts w
Andreas Pflug <[EMAIL PROTECTED]> writes:
> in libpq-be.h isn't present on win32 vc6. Apparently, it
> isn't used in Linux either; libpq will compile without it.
It's there to declare struct timeval, and I'm fairly certain that diking
it out of the header would break things on some platforms. W
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > in libpq-be.h isn't present on win32 vc6. Apparently, it
> > isn't used in Linux either; libpq will compile without it.
>
> It's there to declare struct timeval, and I'm fairly certain that diking
> it out of the header would break
Tom wrote:
It's there to declare struct timeval, and I'm fairly certain that diking
it out of the header would break things on some platforms. Where does
Windows define struct timeval?
struct timeval is defined in winsock.h under vc6.
I'm checking for _MSC_VER now.
Agreed. We define FRONTEND
Andreas Pflug <[EMAIL PROTECTED]> writes:
> elog.h is included in postgres.h, which is included in many
> src/port/*.c. Many of them are pretty straight, not requiring any
> backend specific stuff, so the attached patch will change postgres.h to
> c.h for most of them.
Applied. I did the sys/t
25 matches
Mail list logo
