Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <46459D9E.4090508@kippdata.de>
Date: Sat, 12 May 2007 12:57:34 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [mod_jk] 1.2.22 won't build  (libtool error) :(
References: <464474E6.7040906@christopherschultz.net>
 <46449ABC.5000607@kippdata.de>
 <4644C038.3030308@christopherschultz.net>	 <4644C9BE.3020409@kippdata.de>
 <4644DE7F.9060804@christopherschultz.net>
In-Reply-To: <4644DE7F.9060804@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> Okay, I tried this:
> 
> $ export CC=i486-linux-gnu-gcc
> $ make clean
> $ ./configure --with-apxs=/usr/bin/apxs2
> $ make
> 
> Looks like it works this way. Weird. Why should the name of the compiler
> matter?

The TODO file of libtool says:

* ... This includes writing libtool not to be so dependent on the 
compiler used to configure it.

In fact libtool is there to hide platform specifics from everyone, who 
wants to build libraries (or shared object files). This is done in a 
way, that during libtool creation it analyzes your platform and includes 
its specifics into the libtool file. So the resulting libtool file is 
not portable. Of course all your gcc links were pointing to the same 
file, but libtool simply remembers the name of the compiler.

> Here's another question: why does the configure script build a 'libtool'
> script in the current directory and then not use it? Also, "CC" is set
> correctly in /usr/share/apr-1.0/build/libtool (which appears to be the
> actual libtool being invoked, since I get that debugging output I added
> to it earlier), so what am I missing, here?

We still use the libtool we generate ourselves for building the Apache 
httpd 1.3 mod_jk. Apache httpd 1.3 does not directly use libtool, 
instead it calls gcc -shared to create its own module files.

In case we build an Apache httpd 2.x module, we are using the httpd 
provided instance of libtool for maximum module compatibility. We find 
this libtool by querying apxs -q LIBTOOL.

==== From your other message ====

 > How does CC get picked when configure runs? I tried reading the
 > configure script but got lost pretty quickly.

configure is produced out of configure.in by a toolchain including 
autoconf and automake. In configure.in there is an autoconf macro named 
AC_PROG_CC that includes a predefined script to detect the correct 
compiler. Autoconf contains an info file (documentation), that explains:

  -- Macro: AC_PROG_CC ([COMPILER-SEARCH-LIST])
      Determine a C compiler to use.  If `CC' is not already set in the
      environment, check for `gcc' and `cc', then for other C compilers.
      Set output variable `CC' to the name of the compiler found.
...

So it respects an externally set CC environment variable, and otherwise 
tries to autodetect using build in rules.

 > It looks like apxs knows what CC should be set to, though:
 >
 > $ apxs2 -q CC
 > i486-linux-gnu-gcc
 >
 > Does it make sense for configure to use apxs to configure its compiler?
 > I would certainly try this and submit a patch if I knew the right way to
 > do it ;)

Yes it would make sense. We would need to move the apache specific parts 
(or maybe all of the web server specific parts) from nearly the end of 
configure.in close to the beginning of the file and do the CC and 
LIBTOOL handling only after that. Of course we would need to check for 
settings inside available environment variables, which should still be 
allowed to override the intelligent defaults from apxs. And we could 
produce libtool only for the cases we need it.

I think it's simply a matter of reordering and checking/testing, if we 
don't break any dependencies (like needing to compile something in a 
test before determining the compiler).

Unfortunately I'm not really an autoconf/automake expert (the tools 
which generate configure, Makefile etc. from the *.am and *.in files), 
but I should be able to rearrange the existing configure.in.

Or maybe you'll like to play around a little with configure.in? After 
you change it, you'll need to run buildconf.sh. To be able to use 
buildconf.sh, you'll need autoconf, automake and m4 on your system.
I'm using versions autoconf 2.1, automake 1.10 and m4 1.4.8. Others 
should be OK, if they are not to old.

Regards,

Rainer


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org