Before I call it a bug - some comments and questions
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.
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.
Regards,
Michael
Michael Felt <mamfelt@gmail.com> writes:
-- As I build, generally, as root - this failed because initdb does not want
to run as root
Many people regard that as bad practice ...
--- 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).
Because that's the default installation prefix.
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.
configure --prefix=/some/path
4. Minor point: why is /usr/local/include not in the -I list by default?
That would be something to ask your compiler vendor. It's no business
of postgres' to assume that some non-default -I switches are
appropriate. I believe that gcc is very often configured to include
/usr/local in its default -I path, but that's up to local custom.
regards, tom lane
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
Tom and Chris - thank you for your answers. There are several reasons for
not including /usr/local/include. Some of those reasons are that I do not
want to be adding files to /usr/include - when it concerns dependencies I
have had to build before getting started. But that is my choice. No further
comment.
And while I can understand that pgsql should not run as root, I usually
build as root - so the automatic testing fails. When I ran make as 'michael'
the test failed but an installation to /usr/local started (and failed,
fortunately).
Perhaps it has to do with gmake not being my default make, but what I would
like to see (and what I recall from when I built an version 8.4.2
distribution) is that make just compile it, make test - install it, and
ideally, without modifying the configure command, be able to make an install
to a "distr" area to construct a distribution in a native AIX format
(installp).
Re: the install to distribution area - I'll work on that myself, unless you
know something simple for me. However, I would appreciate suggestions on how
to get make be less all-inclusive.
Thanks again,
Michael
On Thu, Sep 9, 2010 at 5:21 PM, Chris Browne <cbbrowne@acm.org> wrote:
Show quoted text
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 notwant to
run as root
-- su to another user after changing ownership of the files, failsbecause not
enough space (maybe check for space)
-- enlarge filesystem, run make again, tests all succeed, and then makefails
trying to install docs (not root!) --- why is the initial make installing/copying anything outside of theproject
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" failedagain.
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--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Guess this means no further suggestions. I'll hack at it then.
On Fri, Sep 10, 2010 at 2:26 PM, Michael Felt <mamfelt@gmail.com> wrote:
Show quoted text
Tom and Chris - thank you for your answers. There are several reasons for
not including /usr/local/include. Some of those reasons are that I do not
want to be adding files to /usr/include - when it concerns dependencies I
have had to build before getting started. But that is my choice. No further
comment.And while I can understand that pgsql should not run as root, I usually
build as root - so the automatic testing fails. When I ran make as 'michael'
the test failed but an installation to /usr/local started (and failed,
fortunately).Perhaps it has to do with gmake not being my default make, but what I would
like to see (and what I recall from when I built an version 8.4.2
distribution) is that make just compile it, make test - install it, and
ideally, without modifying the configure command, be able to make an install
to a "distr" area to construct a distribution in a native AIX format
(installp).Re: the install to distribution area - I'll work on that myself, unless you
know something simple for me. However, I would appreciate suggestions on how
to get make be less all-inclusive.Thanks again,
MichaelOn Thu, Sep 9, 2010 at 5:21 PM, Chris Browne <cbbrowne@acm.org> wrote:
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 notwant to
run as root
-- su to another user after changing ownership of the files, failsbecause not
enough space (maybe check for space)
-- enlarge filesystem, run make again, tests all succeed, and then makefails
trying to install docs (not root!) --- why is the initial make installing/copying anything outside of theproject
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" failedagain.
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--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs