Re: Before I call it a bug - some comments and questions - Mailing list pgsql-bugs
From | Michael Felt |
---|---|
Subject | Re: Before I call it a bug - some comments and questions |
Date | |
Msg-id | AANLkTik3hDNh02MP+jDU0bxDLDk6MMzHQXdQRVcbtkqe@mail.gmail.com Whole thread Raw |
In response to | Re: Before I call it a bug - some comments and questions (Michael Felt <mamfelt@gmail.com>) |
List | 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 >> > >
pgsql-bugs by date: