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

BUG #4951: installation dir wrong for libpq compilation

From
"Jim Michaels"
Date:
The following bug has been logged online:

Bug reference:      4951
Logged by:          Jim Michaels
Email address:      jmichae3@yahoo.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.

you had it right the first time for 8.3.7 installing pgsql in
c:\postgresplus.  even if it's c:\postgresql that would be fine, just as
long as it's not
c:\program files\postgresql.

besides, on vista c:\program files is a protected directory, and writes to
that directory may end up somewhere else in a virtual store if the program
does not have a vista-compatible manifest.

I get loads of errors saying things are not defined, and an error at the top
saying it could not find libpq.h.

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

From
Craig Ringer
Date:
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@yahoo.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

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

From
Peter Eisentraut
Date:
On Wednesday 29 July 2009 01:57:50 Jim Michaels wrote:
> 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.

Proof please?

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

From
Dave Page
Date:
On Tue, Jul 28, 2009 at 11:57 PM, Jim Michaels<jmichae3@yahoo.com> wrote:
>
> The following bug has been logged online:
>
> Bug reference: =A0 =A0 =A04951
> Logged by: =A0 =A0 =A0 =A0 =A0Jim Michaels
> Email address: =A0 =A0 =A0jmichae3@yahoo.com
> PostgreSQL version: 8.4.0
> Operating system: =A0 Win XP Pro Sp3
> Description: =A0 =A0 =A0 =A0installation dir wrong for libpq compilation
> Details:
>
> it is impossible to compile in libpq headers unless the installation
> directory for postgres has no spaces. =A0compilers such as gcc/mingw don't
> like that.

Double-quoting the paths works fine for me.

> you had it right the first time for 8.3.7 installing pgsql in
> c:\postgresplus.

Postgres Plus is a different product.

> even if it's c:\postgresql that would be fine, just as
> long as it's not
> c:\program files\postgresql.

%ProgramFiles%\xxxx is the Microsoft-recommended installation location
for all applications. Iirc, you can't get a 'Designed for Windows'
certification unless your installation defaults to there. Besides,
it's only a default - if you don't like it, it's trivial to choose
another location.

> besides, on vista c:\program files is a protected directory, and writes to
> that directory may end up somewhere else in a virtual store if the program
> does not have a vista-compatible manifest.

We've done a lot of work to ensure that is never a problem, and after
hundreds of thousands of downloads, it certainly isn't something
anyone has ever reported as an issue that I'm aware of.

Regards, Dave

--=20
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com