Ok, I understand your point of view, I've checked it and /bin/sh on debian 4 points to /bin/bash, you might be right, question is, how do I do fix this.
When I say you might be right is because there are other scripts in jni/native/build which are bourne shell scripts. Those scripts are called when you do a ./configure vserv-deb:/usr/local/build/tomcat-native-1.1.10-src/jni/native# ls -l build total 156 -rw-r--r-- 1 root root 26635 2007-04-23 20:21 apr_common.m4 -rwxr-xr-x 1 500 root 2115 2007-01-05 17:33 buildcheck.sh -rwxr-xr-x 1 root root 44208 2007-04-23 20:21 config.guess -rwxr-xr-x 1 root root 32448 2007-04-23 20:21 config.sub -rw-r--r-- 1 root root 6302 2007-04-23 20:21 find_apr.m4 -rwxr-xr-x 1 500 root 1156 2007-01-05 17:33 get-version.sh -rwxr-xr-x 1 root root 2631 2007-04-23 20:21 install.sh -rw-r--r-- 1 500 root 3633 2007-01-05 21:57 lineends.pl -rwxr-xr-x 1 500 root 980 2007-01-05 17:33 mkdir.sh drwxr-xr-x 2 500 root 4096 2007-04-02 07:07 rpm -rw-r--r-- 1 root root 6149 2007-04-23 20:21 rules.mk -rw-r--r-- 1 500 root 10421 2007-04-02 05:51 tcnative.m4 On the other hand, that already happened on debian 3.1 and I was able to build the hole thing on a client: apache(with apr and apr-util)/tomcat-native/tomcat-connector Same versions I'm trying to build now. Orlando Reis On 4/23/07, Fargusson.Alan <[EMAIL PROTECTED]> wrote:
I just want to make one point clear: Even when you are using bash, if /bin/sh is linked to some other shell, or is a copy of some other shell, then shell scripts may be run by that other shell, and not bash. I have seen problems due to the order in which packages are installed. It seems that some packages link /bin/sh to the shell contained in that package, so even though bash was the default shell to start with, some other shell ends up replacing it, and fails to run configure scripts. -----Original Message----- From: Orlando Reis [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 12:06 PM To: Tomcat Users List Subject: Re: Problem with compiling tomcat native Thanks for the reply Alan. I'm using bash, and have used bash in Solaris, Linux (Centos, RHE5, Fedora, Ubuntu). None of those platforms gave me a headache, only Debian 4.0, with Debian 3.1I didn't have a problem. Orlando On 4/23/07, Fargusson.Alan <[EMAIL PROTECTED]> wrote: > > It may be that the configure script depends on the default shell (/bin/sh) > being BASH. Does it work if you do "bash configure"? > > -----Original Message----- > From: Orlando Reis [mailto:[EMAIL PROTECTED] > Sent: Monday, April 23, 2007 4:25 AM > To: users@tomcat.apache.org > Subject: Problem with compiling tomcat native > > > Hi, I'm having some trouble compiling tomcat-native-1.1.10-src, I've done > this before on several different platforms, but for some reason the > lastest > debian (4.0 etch) is giving me problems. > > vserv-deb:/usr/local/build/tomcat-native-1.1.10-src/jni/native# sh > buildconf > --with-java-home=$JAVA_HOME --with-apr=/usr/local/build/httpd-2.2.4 > /srclib/apr > > Looking for apr source in /usr/local/build/httpd-2.2.4/srclib/apr > Creating configure ... > Generating 'make' outputs ... > rebuilding rpm spec file > vserv-deb:/usr/local/build/tomcat-native-1.1.10-src/jni/native# > ./configure > --with-java-home=$JAVA_HOME --with-apr=/usr/local/apr-httpd > --with-ssl=/usr/local/openssl > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking for working mkdir -p... yes > Tomcat Native Version: 1.1.10 > checking for chosen layout... tcnative > checking for APR... yes > setting CC to "gcc" > setting CPP to "gcc -E" > checking for a BSD-compatible install... /usr/bin/install -c > checking for JDK location (please wait)... /usr/local/java.1.6 > checking Java platform... checking Java platform... > checking for sablevm... NONE > adding "-I/usr/local/java.1.6/include" to TCNATIVE_PRIV_INCLUDES > checking os_type directory... linux > adding "-I/usr/local/java.1.6/include/linux" to TCNATIVE_PRIV_INCLUDES > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for OpenSSL library... using openssl from /usr/local/openssl/lib > and /usr/local/openssl/include > checking OpenSSL library version... ok > checking for OpenSSL DSA support... yes > adding "-I/usr/local/openssl/include" to TCNATIVE_PRIV_INCLUDES > setting TCNATIVE_LDFLAGS to "-L/usr/local/openssl/lib -lssl -lcrypto" > adding "-DHAVE_OPENSSL" to CFLAGS > setting TCNATIVE_LIBS to "" > setting TCNATIVE_LIBS to " /usr/local/apr-httpd/lib/libapr-1.la -lrt > -lcrypt -lpthread -ldl" > ./configure: line 4280: APR_INCLUDES: command not found > ./configure: line 4281: APR_LIBS: command not found > ./configure: line 4282: APR_LIB_TARGET: command not found > ./configure: line 4283: APR_SO_EXT: command not found > ./configure: line 4284: BASH: command not found > ./configure: line 4285: BASH_ARGC: command not found > ./configure: line 4286: BASH_ARGV: command not found > ./configure: line 4287: BASH_LINENO: command not found > ./configure: line 4288: BASH_SOURCE: command not found > ./configure: line 4289: BASH_VERSINFO: command not found > ./configure: line 4290: BASH_VERSION: command not found > ./configure: line 4291: CC: command not found > ./configure: line 4292: CFLAGS: command not found > ./configure: line 4293: CPP: command not found > > > > > > Line 4288 > > _ACEOF > > > # The following way of writing the cache mishandles newlines in values, > # but we know of no workaround that is simple, portable, and efficient. > # So, we kill variables containing newlines. > # Ultrix sh set writes to stderr and can't be redirected directly, > # and sets the high bit in the cache file unless we assign to the vars. > ( > for ac_var in `(set) 2>&1 | sed -n > 's/^\([a-zA-Z_][a-zA-Z0-9_]*\)=.*/\1/p'`; do > eval ac_val=\$$ac_var > case $ac_val in #( > *${as_nl}*) > case $ac_var in #( > *_cv_*) { echo "$as_me:$LINENO: WARNING: Cache variable $ac_var > contains a newline." >&5 > echo "$as_me: WARNING: Cache variable $ac_var contains a newline." >&2;} > ;; > esac > case $ac_var in #( > _ | IFS | as_nl) ;; #( > *) $as_unset $ac_var ;; #line 4288 > esac ;; > esac > done > > > Any ideas? > > Orlando > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
