Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
Rearrange configure.in, such that in case we
got with-apxs we detect CC from apxs and warn,
if the CC environment variable differs.
Is this really needed?
I mean having that the apxs wouldn't work for
any custom module thought.
I think that instead fixing other people mistakes
(here I mean the package producers) we should only
give our users 'howto' instead trying to fix whatever
(in this example Debian maker of httpd) fault might be.
If we start doing that, then we can forget libtool at all.
>
What I have read about the subject the reason for the
patch is because of platform or libtool.
I wonder if on that platform any apxs command can be done.
If not, and if it's cause either because of platform or
libtool bug we should not try to maintain out patches
just to address those issues. I'm sure the user
community will address those problems to the originators
of the bugs itself.
Actually I was running into the same problem long ago myself, without
any platform being guilty and the problem is not very well documented
(w.r.t. Google).
I regularly build httpd with a different specs file for GCC to
statically link in libgcc. To do this, the stablest way is setting
CC="gcc -specs=/my/specsfile".
If you do something like this, the libtool generated while building
httpd will contain
CC="gcc -specs=/my/specsfile"
If you use this libtool later on with a value of CC which does not start
with "gcc -specs=/my/specsfile", libtool throws an error and your build
will stop.
So I think the problem is the subtle way the build toolchain depends on
the build environment during httpd build vs. mod_jk build. Warning in
case of incompatibilities seems to be reasonable.
At least 90% of this patch are coming from moving the with-apxs part in
front. Only few logic was added to configure.in: setting CC from apxs
(if it is not set in the environment), before running the compiler tests
and the final warning about differences between apxs CC and environment CC.
This way, we learn the CC command from apxs (as we should) and we warn,
if there are incompatibilities with what the user has chosen.
That's why, -1 on anything trying to 'patch' the
misbehavior of the documented tools for any platform.
I think it's not trying to patch misbehaviour, but simply using the
toolchain to build extension modules for httpd in the way it is meant to
be. There is a good reason for "apxs -q CC" and we already used "apxs -q
CFLAGS".
I would have preferred the documentation thing, if there wouldn't have
been a clean way to rearrange the configure.in, but I don't see a new
problem from the way it is now (maybe i'm simply blind).
Regards,
Mladen
Still vetoing?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
