Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 59899

Summary: Tomcat 5 fails to install at multiple points throughout an installation attempt (including autoconf usage)
Product: Gentoo Linux Reporter: Justin Gombos <bugzilla.gentoo.jgombos>
Component: Current packagesAssignee: ppc64 architecture team <ppc64>
Status: VERIFIED UPSTREAM    
Severity: normal CC: java
Priority: High    
Version: 2004.2   
Hardware: PPC64   
OS: Linux   
URL: http://forums.gentoo.org/viewtopic.php?t=208259
Whiteboard:
Package list:
Runtime testing required: ---

Description Justin Gombos 2004-08-09 14:26:37 UTC
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]
Comment 1 Justin Gombos 2004-08-10 09:12:31 UTC
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.
Comment 2 Justin Gombos 2004-08-10 09:50:46 UTC
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
Comment 3 Justin Gombos 2004-08-10 12:00:01 UTC
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
Comment 4 Markus Rothe (RETIRED) gentoo-dev 2004-11-03 13:27:26 UTC
problem still present? any progress?

Markus
Comment 5 Markus Rothe (RETIRED) gentoo-dev 2004-11-17 09:01:41 UTC
works fine for me! seems to be fixed upstream? if no, please reopen this bug.
Comment 6 Markus Rothe (RETIRED) gentoo-dev 2004-11-17 09:01:52 UTC
closing...