Skip site navigation (1) Skip section navigation (2)

Re: BUG #4951: installation dir wrong for libpq compilation

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Jim Michaels <jmichae3(at)yahoo(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4951: installation dir wrong for libpq compilation
Date: 2009-07-29 07:36:11
Message-ID: 1248852971.14817.4.camel@ayaki (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Tue, 2009-07-28 at 22:57 +0000, Jim Michaels wrote:
> The following bug has been logged online:
> Bug reference:      4951
> Logged by:          Jim Michaels
> Email address:      jmichae3(at)yahoo(dot)com
> PostgreSQL version: 8.4.0
> Operating system:   Win XP Pro Sp3
> Description:        installation dir wrong for libpq compilation
> Details: 
> it is impossible to compile in libpq headers unless the installation
> directory for postgres has no spaces.  compilers such as gcc/mingw don't
> like that. 

I use mingw32 with include paths that contain spaces all the time. Not
for PostgreSQL admittedly, but for other projects.

Use the -I directive with "double quotes" on the path, or use a Windows
PATH-style semicolon-separated directory list in the CPATH environment
variable, eg

set CPATH=%CPATH%;C:\PROGRAM FILES\PostgreSQL\8.3\include

Really, gcc doesn't care, either in its various native forms nor as
mingw32. Nor does GNU make. However, build scripts and sloppily written
makefiles may fail to properly quote variable substitutions, which will
lead to problems. The answer is to fix the build scripts, not move the
header files.

If you're really stuck with build scripts or tools you can't change, you
can always create an NTFS junction point (like a symbolic link) to remap
the include dir somewhere else.

Craig Ringer

In response to

pgsql-bugs by date

Next:From: Peter EisentrautDate: 2009-07-29 08:35:25
Subject: Re: BUG #4951: installation dir wrong for libpq compilation
Previous:From: Dan BoeriuDate: 2009-07-29 05:05:52
Subject: Re: BUG #4945: Parallel update(s) gone wild

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group