Thread: 7.4 build problem on Linux Vserver

Hi all,

I get the following build error when attempting to build 7.4 in a Linux
Vserver (like a FreeBSD jail) built on Slackware 9.1 with the 2.4.22
kernel:

make -C doc all
make[1]: Entering directory `/usr/local/src/postgresql-7.4/doc'
gzip -d -c man.tar.gz | /bin/tar xf -
for file in man1/*.1; do \ mv $file $file.bak && \ sed -e 's/\\fR(l)/\\fR(7)/' $file.bak >$file && \ rm -f $file.bak ||
exit;\ 
done
/bin/sh ../config/mkinstalldirs man7
mkdir man7
for file in manl/*.l; do \ sed -e '/^\.TH/s/"l"/"7"/'   \             -e 's/\\fR(l)/\\fR(7)/' \     $file
>man7/`basename$file | sed 's/.l$/.7/'` || exit; \ done 
make[1]: Leaving directory `/usr/local/src/postgresql-7.4/doc'
make -C src all
make[1]: Entering directory `/usr/local/src/postgresql-7.4/src'
make -C port all
make[2]: Entering directory `/usr/local/src/postgresql-7.4/src/port'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations prod -I../../src/include -D_GNU_SOURCE
-I/usr/include  -c -o path.o path.c
gcc: cannot specify -o with -c or -S and multiple compilations
make[2]: *** [path.o] Error 1
make[2]: Leaving directory `/usr/local/src/postgresql-7.4/src/port'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/postgresql-7.4/src'
make: *** [all] Error 2

root@developer:/usr/local/src/postgresql-7.4# uname -a Linux
developer.pgadmin.org 2.4.22-vs1.20 #14 SMP Wed Dec 10 19:49:23 GMT 2003
i686 unknown unknown GNU/Linux

root@developer:/usr/local/src/postgresql-7.4# gcc --version gcc (GCC)
3.2.3 Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Configured with: ./configure --with-openssl=/usr

Any ideas what may be causing this?

Thanks, Dave.

"Dave Page" <dpage@vale-housing.co.uk> writes:
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations prod -I../../src/include -D_GNU_SOURCE
> -I/usr/include  -c -o path.o path.c
> gcc: cannot specify -o with -c or -S and multiple compilations

How is "prod" getting into that command line?  I suspect it's coming
from an environment variable like PROFILE or CFLAGS ...
        regards, tom lane

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 11 December 2003 15:31
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 7.4 build problem on Linux Vserver
>
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> > -Wmissing-declarations prod -I../../src/include -D_GNU_SOURCE
> > -I/usr/include  -c -o path.o path.c
> > gcc: cannot specify -o with -c or -S and multiple compilations
>
> How is "prod" getting into that command line?  I suspect it's
> coming from an environment variable like PROFILE or CFLAGS ...

Aha - the vserver code uses a var called PROFILE which is set to prod
(meaning production). Unsetting has allowed the compile to run as
normal.

Thanks Tom.

Regards, Dave.

Tom Lane wrote:

>"Dave Page" <dpage@vale-housing.co.uk> writes:
>  
>
>>gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
>>-Wmissing-declarations prod -I../../src/include -D_GNU_SOURCE
>>-I/usr/include  -c -o path.o path.c
>>gcc: cannot specify -o with -c or -S and multiple compilations
>>    
>>
>
>How is "prod" getting into that command line?  I suspect it's coming
>from an environment variable like PROFILE or CFLAGS ...
>
>    
>

Is there a case for making Makefile/shell variables and defines we use 
have less generic names? I know I encountered a problem on Windows when 
doing initdb because it defines one of BINDIR/DATADIR (I forget which). 
It took me ages to find out what was going on, and I fixed it by 
prepending the variable (in this case a define) with "PG"

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> How is "prod" getting into that command line?  I suspect it's coming
>> from an environment variable like PROFILE or CFLAGS ...

> Is there a case for making Makefile/shell variables and defines we use 
> have less generic names?

Having configure/make depend on CC, CFLAGS, etc is standard behavior;
renaming those would increase the surprise factor, not reduce it.

PROFILE is maybe a borderline case, since I'm not sure how many packages
use it the way we do.  But I'd be at least as inclined to blame Dave's
environment for using a generic variable name as blame our makefiles.
        regards, tom lane

On Thu, 11 Dec 2003, Dave Page wrote:

> > "Dave Page" <dpage@vale-housing.co.uk> writes:
> > > gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes 
> > > -Wmissing-declarations prod -I../../src/include -D_GNU_SOURCE 
> > > -I/usr/include  -c -o path.o path.c
> > > gcc: cannot specify -o with -c or -S and multiple compilations
> > 
> > How is "prod" getting into that command line?  I suspect it's 
> > coming from an environment variable like PROFILE or CFLAGS ...
> 
> Aha - the vserver code uses a var called PROFILE which is set to prod
> (meaning production). Unsetting has allowed the compile to run as
> normal.
> 
> Thanks Tom.
> 
> Regards, Dave.


And thanks to you Dave for finding this before I even found the time to 
search for it.

I'm cc this to the vserver list so they are aware of the issue.


Rod
--    "Open Source Software - You usually get more than you pay for..."    "Build A Brighter Lamp :: Linux Apache
{middleware}PostgreSQL"