Doing an emerge tomcat appears to work correctly with ACCEPT_KEYWORDS set to ~ppc64. However when I try to invoke startup.sh or /etc/init.d/tomcat start, I get the following output on both attempts: Starting Tomcat... Using CATALINA_BASE: /opt/tomcat5 Using CATALINA_HOME: /opt/tomcat5 Using CATALINA_TMPDIR: /opt/tomcat5/temp Using JAVA_HOME: /opt/ibm-jdk-bin-1.4.2 Usage: catalina.sh ( commands ... ) commands: debug Start Catalina in a debugger debug -security Debug Catalina with a security manager jpda start Start Catalina under JPDA debugger run Start Catalina in the current window run -security Start in the current window with security manager start Start Catalina in a separate window start -security Start in a separate window with security manager stop Stop Catalina stop -force Stop Catalina (followed by kill -KILL) It appears that the startup.sh script misuses catalina.sh. But digging deeper, it appears that emerge did not compile the binaries at all. There is no jsvc binary to be found on the system. The $CATALINA_HOME/bin folder contains a tarball that was never unpacked. So I unpacked it manually, and ran autoconf (as per the Tomcat install guide). The results of that were: autoconf autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH ***BUG in Autoconf--please report*** AC_PATH The workaround for this is to "export WANT_AUTOCONF_2_5=1". The next step is to run ./configure, and that errors as follows:Code: ./configure loading cache ./config.cache *** Current host *** checking host system type... ./support/config.guess: unable to guess system type This script, last modified 2001-04-20, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from ftp://ftp.gnu.org/pub/gnu/config/ If the version you run (./support/config.guess) is already up to date, please send the following data and any information you think might be pertinent to <config-patches@gnu.org> in order to provide the needed information to handle your system. config.guess timestamp = 2001-04-20 uname -m = ppc64 uname -r = 2.6.7-gentoo-r11 uname -s = Linux uname -v = #1 SMP Wed Aug 4 09:01:07 UTC 2004 /usr/bin/uname -p = PPC970, altivec supported /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = ppc64 /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = ppc64 UNAME_RELEASE = 2.6.7-gentoo-r11 UNAME_SYSTEM = Linux UNAME_VERSION = #1 SMP Wed Aug 4 09:01:07 UTC 2004 configure: error: can not guess host type; you must specify one It appears that this script cannot handle a uname -m return value of "ppc64". Reproducible: Always Steps to Reproduce: (steps provided in details) Actual Results: (error results provided in details) Expected Results: Error free execution of Tomcat might have produced output similar to: Starting Tomcat... Using CATALINA_BASE: /opt/tomcat5 Using CATALINA_HOME: /opt/tomcat5 Using CATALINA_TMPDIR: /opt/tomcat5/temp Using JAVA_HOME: /opt/ibm-jdk-bin-1.4.2 Tomcat 5 started [OK]
I hacked my "arch" and "uname" commands so they would falsely report "ppc" instead of "ppc64." This worked for building the binary. So if there are any bash experts here, there's probably a clean way to do this in bash. Also, fixing this so that the binary builds correctly does not correct the original problem of startup.sh misusing the catalina.sh script. So it seems there are at least two bugs here.
After further investigation, catalina.sh is not being misused. When usage is correct, catalina.sh still prints out the syntax description, and fails to kick off the server. Furthermore, bypassing the script and running jsvc directly results in this error log: jsvc.exec error: Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader jsvc.exec error: Service exit with a return value of 1
The java bug *may* actually not be a packaging issue, but a problem internal to Tomcat. So that bug has been documented here: http://issues.apache.org/bugzilla/show_bug.cgi?id=30568
problem still present? any progress? Markus
works fine for me! seems to be fixed upstream? if no, please reopen this bug.
closing...
