Thread: Compiling Postgresql 8.0.3 on Solaris 10
Hello Folks,
I hope that you are well. I tried compiling Postgres 8.0.3 on Solaris 10 and
encountered the following problem, has anybody else had problems. I know that I
have gcc3 installed and working, compiled apache with it as well as a small test
program. This is a Sun Blade 150 with about 1GB RAM.
[dharshi::02:03 PM::~/downloads/postgresql-8.0.3]$ ./configure
rm: remove conftest.sh (yes/no)? y
rm: remove conf29127 (yes/no)? y
rm: remove conf29127.file (yes/no)? y
rm: remove conftest.c (yes/no)? y
rm: remove confdefs.h (yes/no)? y
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking which template to use... solaris
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for C compiler default output... -rwx------
checking whether the C compiler works... configure: error: cannot run C compiled
programs.
If you meant to cross compile, use `--host'.
rm: remove conftest.c (yes/no)? y
rm: remove confdefs.h (yes/no)? y
rm: remove a.out (yes/no)? y
Any help would be appreciated.
Cheers,
Aly.
---
Aly Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"
After 5 seconds of intense thought, I suggest that you
check the privileges on your compiler stuff.
Please keep posting and let us know how you fared.
-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Aly Dharshi
Sent: Wednesday, May 25, 2005 4:12 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Compiling Postgresql 8.0.3 on Solaris 10
Hello Folks,
I hope that you are well. I tried compiling Postgres 8.0.3 on Solaris 10 and
encountered the following problem, has anybody else had problems. I know that I
have gcc3 installed and working, compiled apache with it as well as a small test
program. This is a Sun Blade 150 with about 1GB RAM.
[dharshi::02:03 PM::~/downloads/postgresql-8.0.3]$ ./configure
rm: remove conftest.sh (yes/no)? y
rm: remove conf29127 (yes/no)? y
rm: remove conf29127.file (yes/no)? y
rm: remove conftest.c (yes/no)? y
rm: remove confdefs.h (yes/no)? y
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking which template to use... solaris
checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for
defaultport number... 5432 checking for C compiler default output... -rwx------ checking whether the C compiler
works...configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'.
rm: remove conftest.c (yes/no)? y
rm: remove confdefs.h (yes/no)? y
rm: remove a.out (yes/no)? y
Any help would be appreciated.
Cheers,
Aly.
---
Aly Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Aly Dharshi <aly.dharshi@telus.net> writes:
> I hope that you are well. I tried compiling Postgres 8.0.3 on Solaris 10 and
> encountered the following problem, has anybody else had problems.
> [dharshi::02:03 PM::~/downloads/postgresql-8.0.3]$ ./configure
> rm: remove conftest.sh (yes/no)? y
> rm: remove conf29127 (yes/no)? y
> rm: remove conf29127.file (yes/no)? y
> rm: remove conftest.c (yes/no)? y
> rm: remove confdefs.h (yes/no)? y
> checking build system type... sparc-sun-solaris2.10
> checking host system type... sparc-sun-solaris2.10
> checking which template to use... solaris
> checking whether to build with 64-bit integer date/time support... no
> checking whether NLS is wanted... no
> checking for default port number... 5432
> checking for C compiler default output... -rwx------
> checking whether the C compiler works... configure: error: cannot run C compiled
> programs.
> If you meant to cross compile, use `--host'.
> rm: remove conftest.c (yes/no)? y
> rm: remove confdefs.h (yes/no)? y
> rm: remove a.out (yes/no)? y
That's fairly bizarre --- first that you're being queried about "rm"
actions and second that the "default output" check prints something
weird instead of a file name. I think that the configure script is
getting messed up by "rm" and "ls" aliases intended for interactive
work. Which suggests that you are using the wrong shell to execute the
configure script, because a plain Bourne shell has no such aliases.
Do you have /bin/sh pointed to something other than a plain Bourne shell?
Another possibility is that you have scripts for "rm" and "ls" in your
search path ahead of the standard programs.
regards, tom lane
Hello Tom,
I hope that you are well. I tried to check my aliases in my current shell which
is bash (/bin/bash):
alias allproc='ps -ef | less'
alias cls='clear'
alias e='emacs -nw $1'
alias e-mail='pine'
alias ll='colorls -l'
alias lo='exit'
alias logout='exit'
alias ls='colorls -al'
alias mproc='ps -ef | grep $USER'
alias rm='rm -i'
alias rmf='/bin/rm -f'
alias rmp='/bin/rm'
alias rmtmp='rm -i core *~ *.*~ .*~ .pine-debug*'
In the plain vanilla sh shell (/usr/bin/sh) I get the same problems:
autoload='typeset -fu'
command='command '
functions='typeset -f'
history='fc -l'
integer='typeset -i'
local=typeset
nohup='nohup '
r='fc -e -'
stop='kill -STOP'
suspend='kill -STOP $$'
Please note that I built Apache 2.0.53 in the same environment without any
problems. I don't see any aliases that are going to break the compile process.
Cheers,
Aly.
--
Aly Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"
Aly Dharshi <aly.dharshi@telus.net> writes:
> alias ls='colorls -al'
> alias rm='rm -i'
> I don't see any aliases that are going to break the compile process.
I beg to differ --- I think the ones quoted above match your symptoms
pretty well. So the question is: why are they getting used in a
noninteractive script?
My bet is that you've defined these aliases in the wrong place.
I'm not sure about Solaris, but on Linux one conventionally puts
aliases like these in ~/.bashrc, which I think is not read by
plain sh. If you've put them in ~/.profile they are very likely
to break shell scripts.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Aly Dharshi <aly.dharshi@telus.net> writes:
> > alias ls='colorls -al'
> > alias rm='rm -i'
>
> > I don't see any aliases that are going to break the compile process.
>
> I beg to differ --- I think the ones quoted above match your symptoms
> pretty well. So the question is: why are they getting used in a
> noninteractive script?
>
> My bet is that you've defined these aliases in the wrong place.
> I'm not sure about Solaris, but on Linux one conventionally puts
> aliases like these in ~/.bashrc, which I think is not read by
> plain sh. If you've put them in ~/.profile they are very likely
> to break shell scripts.
This doesn't really seem like a sufficient explanation. Putting such things in
.profile is pretty standard too. .profile should only ever be run by login
shells -- not even all interactive shells -- in the first place.
Moreover, bash at least will not expand aliases for non-interactive shells:
Aliases are not expanded when the shell is not interactive, unless the
expand_aliases shell option is set using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS below).
So either this user has this expand_aliases shell option set. Or he's using
Solaris's /bin/sh which is a non-POSIX ksh derivative and that shell is both
1) running .profile for a non-interactive shell (which is utterly bogus) and
2) expanding aliases for a non-interactive shell.
I'm skeptical that it's doing that and if it is then it would be causing
problems for virtually any /bin/sh script. *Many* users would have commands in
.profile that are intended to only run once at login time.
I suspect something stranger going on. Perhaps /bin/sh on this machine is bash
and this user has some environment variable set that enables this non-standard
behaviour?
--
greg
Hello Tom,
I hope that you are well, thank you for your guidence, but these are indeed
defined in my .bashrc:
# .bashrc
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
if [ "$PS1" ]; then
# your settings:
PS1="[\u@\h::\@::\w]\\$ "
fi
alias cls=clear
alias e\-mail=pine
alias e='emacs -nw $1'
alias rmf='/bin/rm -f'
alias rmp='/bin/rm'
alias rm='rm -i'
alias logout=exit
alias lo=exit
alias rmtmp='rm -i core *~ *.*~ .*~ .pine-debug*'
alias mproc='ps -ef | grep $USER'
alias allproc='ps -ef | less'
alias ll='colorls -l'
alias ls='colorls -al'
I don't see why colorls would do anything different, or for that matter rm -i,
shouldn't the shell scripts *not* use the user's environment and detect that
there is /bin/rm and that ls is /bin/ls etc etc. Secondly, I did login and typed
sh, which dumped me into the sh shell, in my previous e-mail I showed the alias
listings in that shell. I tried compiling in that shell and it seems that it
presents the same problems.
Cheers,
Aly.
Tom Lane wrote:
> Aly Dharshi <aly.dharshi@telus.net> writes:
>
>>alias ls='colorls -al'
>>alias rm='rm -i'
>
>
>>I don't see any aliases that are going to break the compile process.
>
>
> I beg to differ --- I think the ones quoted above match your symptoms
> pretty well. So the question is: why are they getting used in a
> noninteractive script?
>
> My bet is that you've defined these aliases in the wrong place.
> I'm not sure about Solaris, but on Linux one conventionally puts
> aliases like these in ~/.bashrc, which I think is not read by
> plain sh. If you've put them in ~/.profile they are very likely
> to break shell scripts.
>
> regards, tom lane
--
Aly Dharshi
aly.dharshi@telus.net
"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"
Greg Stark <gsstark@mit.edu> writes:
> I suspect something stranger going on.
I'm still wondering about the theory that it's not the aliases at issue,
but some scripts in the PATH ahead of the normal /bin/ls and friends.
regards, tom lane