From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vince Vielhaber <vev(at)michvhf(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] report for Win32 port |
Date: | 1999-05-27 00:40:58 |
Message-ID: | 21526.927765658@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vince Vielhaber <vev(at)michvhf(dot)com> writes:
> I've just discovered that libpq++'s makefile uses whatever is defined as
> CXX for the compiler.
As it should ...
> When I force it to use g++28 (ver 2.8.1), it misses /usr/include/g++.
> Adding that to the list of CXXFLAGS fixes that. Now then.. Will it
> break something on another platform if I were to leave that in the
> list?
Absolutely. For example: if someone has both g++ and a vendor C++
compiler installed, and tries to compile with the vendor C++, that
would fail because you'd be forcing the vendor C++ to try to eat
g++-specific include files.
The right place to fix any problem along this line is in configure,
*not* by hardwiring platform-dependent assumptions into libpq++'s
makefile.
If it's actually necessary to do what you suggest, then the way to
do it would be for configure to add -I/usr/include/g++ to CXXFLAGS
after checking that CXX is g++. However, I misdoubt that you have
diagnosed the problem correctly, because the versions of gcc/g++
that I've used automatically include their private include areas into
the -I list. This smells more like an incorrect installation of
g++ than a problem that Postgres ought to be solving.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas A. Szybist | 1999-05-27 00:49:15 | Re: [HACKERS] Problem in S_LOCK? |
Previous Message | Bruce Momjian | 1999-05-27 00:10:29 | Re: [HACKERS] Re: create index updates nrows statistics |