Re: Before I call it a bug - some comments and questions

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Before I call it a bug - some comments and questions
Date: 2010-09-09 15:21:59
Message-ID: 87hbhzlz6w.fsf@cbbrowne.afilias-int.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

mamfelt(at)gmail(dot)com (Michael Felt) writes:
> I have just run compiled postgres on AIX (AIX 5.3, pgsql version 8.4.4) and
> have a few surprises regarding the make process.
>
> 1. Very nice - it found gmake as /usr/local/bin/make and called GNUmakefile
> 2. The make completes and it starts a test.
> -- As I build, generally, as root - this failed because initdb does not want to
> run as root
> -- su to another user after changing ownership of the files, fails because not
> enough space (maybe check for space)
> -- enlarge filesystem, run make again, tests all succeed, and then make fails
> trying to install docs (not root!)
> --- why is the initial make installing/copying anything outside of the project
> directory (in this case it was /usr/local/pgsql if I recall correctly).
> --- My non-root user has no right to write there, so the "build" failed again.
>
> 3. A question: what is the best way to get the make process to install in a
> alturnate directory. Some projects use an environment variable.

See the output of

./configure --help

Commonly, I find it sufficient to specify the alternate location via:

./configure --prefix=/path/where/pg/stuff/should/live

That implies bin/, include/, share/, lib/ and other such target
directories. If you have very specific needs, configure options should
hopefully accommodate them.

> 4. Minor point: why is /usr/local/include not in the -I list by default? I had
> to add CFLAGS=-I/usr/local/include for configure to complete.

That's not a standard place to put #include files across all of the
operating systems on which Postgres runs, so it wouldn't be proper to
have it as a default.

Not all systems have /usr/local/include, and on some systems, adding
this would point the compile to *wrong* code. Consider the case where
an engineer at a company like Red Hat (Tom? ;-)) is building official
packages for a Linux distribution.

- On the machine where the build is being done, there might well exist a
/usr/local/include directory.

- But it shouldn't be used, because the *right* #includes to use for the
build are in /usr/include.

- They might have /usr/local/include there specifically as a test that
programs should *NOT* be referencing it without specific instruction
to do so! I could imagine stowing #includes there that are designed
to make stuff break. Probably not a good thing on an Official Build
Server, but an excellent torture test for a QA server :-).

--
(format nil "~S(at)~S" "cbbrowne" "gmail.com")
The statistics on sanity are that one out of every four Americans is
suffering from some form of mental illness. Think of your three best
friends. If they're okay, then it's you. -- Rita Mae Brown

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Llewellyn 2010-09-09 16:22:51 BUG #5650: Postgres service showing as stopped when in fact it is running
Previous Message Tom Lane 2010-09-09 15:14:36 Re: Before I call it a bug - some comments and questions