Thread: 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: > 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 > > -- > 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: > 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: > >> 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 >> >> -- >> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-bugs >> > >