Re: Before I call it a bug - some comments and questions - Mailing list pgsql-bugs

From Chris Browne
Subject Re: Before I call it a bug - some comments and questions
Date
Msg-id 87hbhzlz6w.fsf@cbbrowne.afilias-int.info
Whole thread Raw
In response to Before I call it a bug - some comments and questions  (Michael Felt <mamfelt@gmail.com>)
Responses Re: Before I call it a bug - some comments and questions
List pgsql-bugs
mamfelt@gmail.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@~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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Before I call it a bug - some comments and questions
Next
From: "Mark Llewellyn"
Date:
Subject: BUG #5650: Postgres service showing as stopped when in fact it is running