Обсуждение: 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