You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Enrico Weigelt <we...@metux.de> on 2004/12/07 02:38:39 UTC
Problem w/ apache-2.0.52 + php-4.3.9: unresolved symbol ap_loaded_modules
Hi folks,
I'm currently trying to get apache-2.0.52 and php-4.3.9 running
together. The httpd has several modules compiled-in and php should
be loaded as .so
The build works quite fine (well, crosscompiling w/ sysroot does
not work w/ apxs :(( ), but when I try to start httpd with
the php4 module loaded I get the error:
undefined symbol: ap_loaded_modules
It seems the httpd's symbols are not exported to the php module
on load.
How can I fix this ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: autoshit addiction [WAS: [PATCH] fixing broken gnu ld (mis)detection problem]
Posted by André Malo <nd...@perlig.de>.
* Enrico Weigelt wrote:
> Again its an autoconf problem. More than just a bug.
I'm wondering why you report it *here*. Sure, it's interesting, but did you
consider opening a bug report at the autoconf site?
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://pub.perlig.de/> #
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Joe Orton <jo...@redhat.com> wrote:
<snip>
> You must run buildconf to regenerate the APR configure script, which is
> the one which configures libtool and has references to egrep. Again, it
> looks fine here with autoconf 2.59:
>
> $ cd httpd-2.0.52
> $ grep egrep srclib/apr/configure
> ...
> if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
> if $LD --help 2>&1 | egrep 'no-whole-archive' > /dev/null; then
> $ ./buildconf
> rebuilding srclib/apr/configure
> buildconf: checking installation...
> buildconf: autoconf version 2.59 (ok)
> buildconf: libtool version 1.5.8 (ok)
> ...
> $ grep egrep srclib/apr/configure
> echo "$as_me:$LINENO: checking for egrep" >&5
> echo $ECHO_N "checking for egrep... $ECHO_C" >&6
> if test "${ac_cv_prog_egrep+set}" = set; then
> then ac_cv_prog_egrep='grep -E'
> else ac_cv_prog_egrep='egrep'
> echo "$as_me:$LINENO: result: $ac_cv_prog_egrep" >&5
> echo "${ECHO_T}$ac_cv_prog_egrep" >&6
> EGREP=$ac_cv_prog_egrep
Well, I already tried it. With no effect.
The configure script remains unchanged.
There's a check for grep/egrep, but not always used, ie. the lines
where ld is detected. (see configure:7870)
Ergo: Apache is still ununsable on platforms with grep 2.4.x.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Dec 14, 2004 at 06:58:06PM +0100, Enrico Weigelt wrote:
> * Joe Orton <jo...@redhat.com> wrote:
>
> > Yeah, that was fixed in 1.5.10. For an autoconf 2.59-generated
> > configure script the only reference to "grep -E" is in the test to see
> > whether grep -E works or not, so that looks fixed to me too.
>
> well, i've tried to regenerate configure with the newest autoconf,
> but without any effect. new and old files dont differ.
You must run buildconf to regenerate the APR configure script, which is
the one which configures libtool and has references to egrep. Again, it
looks fine here with autoconf 2.59:
$ cd httpd-2.0.52
$ grep egrep srclib/apr/configure
...
if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
if $LD --help 2>&1 | egrep 'no-whole-archive' > /dev/null; then
$ ./buildconf
rebuilding srclib/apr/configure
buildconf: checking installation...
buildconf: autoconf version 2.59 (ok)
buildconf: libtool version 1.5.8 (ok)
...
$ grep egrep srclib/apr/configure
echo "$as_me:$LINENO: checking for egrep" >&5
echo $ECHO_N "checking for egrep... $ECHO_C" >&6
if test "${ac_cv_prog_egrep+set}" = set; then
then ac_cv_prog_egrep='grep -E'
else ac_cv_prog_egrep='egrep'
echo "$as_me:$LINENO: result: $ac_cv_prog_egrep" >&5
echo "${ECHO_T}$ac_cv_prog_egrep" >&6
EGREP=$ac_cv_prog_egrep
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Joe Orton <jo...@redhat.com> wrote:
> Yeah, that was fixed in 1.5.10. For an autoconf 2.59-generated
> configure script the only reference to "grep -E" is in the test to see
> whether grep -E works or not, so that looks fixed to me too.
well, i've tried to regenerate configure with the newest autoconf,
but without any effect. new and old files dont differ.
ergo problem remains unsolved, a clean build is nearly impossible.
btw: i've tried the --with-gnu-ld option, but also without any
noticable effect.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Dec 14, 2004 at 09:00:58AM +0000, Joe Orton wrote:
> Yeah, that was fixed in 1.5.10. For an autoconf 2.59-generated
> configure script the only reference to "grep -E" is in the test to see
> whether grep -E works or not, so that looks fixed to me too.
Excellent. So we've wasted all this bandwidth over bugs that have already
been fixed. I'm sure that makes a lot of sense to someone. =) -- justin
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Dec 13, 2004 at 03:35:38PM -0800, Justin Erenkrantz wrote:
> --On Monday, December 13, 2004 5:29 AM +0100 Enrico Weigelt
> <we...@metux.de> wrote:
>
> >>we don't maintain configure;
> >bad enough. an carefully hand-written configure would be much better.
>
> Been there, done that with APACI. We ain't going back to a hand-written
> configure.
>
> AIUI, your problem is fixed if we roll with current autoconf and libtool
> versions. I've been using ac 2.59 and lt 1.5.10 for 2.1.x releases - do
> they work for you out-of-the-box? I don't know of any particular reason
> why we shouldn't do so for new releases of 2.0 as well. (I think the only
> reason against lt 1.5.x is that it requires a C++ compiler which throws AIX
> and other barebones systems for a curve - don't know if that was fixed...)
Yeah, that was fixed in 1.5.10. For an autoconf 2.59-generated
configure script the only reference to "grep -E" is in the test to see
whether grep -E works or not, so that looks fixed to me too.
joe
Re: autoshit addiction [WAS: [PATCH] fixing broken gnu ld (mis)detection problem]
Posted by Enrico Weigelt <we...@metux.de>.
* Patrick Welche <pr...@newn.cam.ac.uk> wrote:
<snip>
> Does this mean the following macro should appear somewhere in
> httpd's configury?
>
> -- Macro: AC_PROG_EGREP
> Check whether `$GREP -E' works, or else search the user's `PATH'
> for `egrep', and `gegrep', in that order, and set output variable
> `EGREP' to the one that accepts the longest input lines.
partially.
we could check if egrep is working with extended regex.
trying to detect the right grep command and setting up an variable
wouldn't help much, since the rest of the autoconf stuff simply
doesn't use it. i had exactly this problem in a couple of other packages.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: autoshit addiction [WAS: [PATCH] fixing broken gnu ld (mis)detection problem]
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Tue, Dec 14, 2004 at 05:33:26AM +0100, Enrico Weigelt wrote:
> It is of these macros which are doing regex test. My build system runs
> the GNU grep v. 2.4.1. A short look the grep --help exposes, that the
> -E option has to be passed when using extendet regex. Simply calling
> egrep does not work here. On another system, running newer grep (2.5.1)
> evrything is fine. So it seems gnu grep changed its behaviour when
> called as egrep - in general a very bad thing.
>
> The only clean solutions are:
>
> a) use the old semantics
> b) encapsulate the grep command (into a shell function) and first
> check which version to use
> c) define grep-2.5.x as an build-tool dependency, check if its really
> installed and working an spit out at least an warning if it doesnt.
>
> Again its an autoconf problem. More than just a bug.
Does this mean the following macro should appear somewhere in
httpd's configury?
-- Macro: AC_PROG_EGREP
Check whether `$GREP -E' works, or else search the user's `PATH'
for `egrep', and `gegrep', in that order, and set output variable
`EGREP' to the one that accepts the longest input lines.
Cheers,
Patrick
autoshit addiction [WAS: [PATCH] fixing broken gnu ld (mis)detection problem]
Posted by Enrico Weigelt <we...@metux.de>.
* Justin Erenkrantz <ju...@erenkrantz.com> wrote:
<snip>
> AIUI, your problem is fixed if we roll with current autoconf and libtool
> versions. I've been using ac 2.59 and lt 1.5.10 for 2.1.x releases - do
> they work for you out-of-the-box? I don't know of any particular reason
No, doesn't make a single change.
configure remains *exactly* the same.
It is of these macros which are doing regex test. My build system runs
the GNU grep v. 2.4.1. A short look the grep --help exposes, that the
-E option has to be passed when using extendet regex. Simply calling
egrep does not work here. On another system, running newer grep (2.5.1)
evrything is fine. So it seems gnu grep changed its behaviour when
called as egrep - in general a very bad thing.
The only clean solutions are:
a) use the old semantics
b) encapsulate the grep command (into a shell function) and first
check which version to use
c) define grep-2.5.x as an build-tool dependency, check if its really
installed and working an spit out at least an warning if it doesnt.
Again its an autoconf problem. More than just a bug.
It would be much, much easier to fix, if we wouldn't use a set of scripts
processing some macros to creat some script which creates another set of
macros for building software, dependent on moon phase and falling of
chineese rice bags.
Instead we should use *one* tool, which as an determinsitic, clear and
constant syntax on all platforms an is ported *once* per target platform.
This would solve this problem *once* for all time and all packages currently
hacking with pot of macros.
> why we shouldn't do so for new releases of 2.0 as well. (I think the only
> reason against lt 1.5.x is that it requires a C++ compiler which throws AIX
> and other barebones systems for a curve - don't know if that was fixed...)
eh, if recent libtool requires an c++ compiler, it definitely becomes
the wrong direction for further thoughts.
Did I already post the wiki-link to my unitool concepts ?
http://nibiru.borg.metux.de:7000/wiki/index.php/Universal_Toolchain
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, December 13, 2004 5:29 AM +0100 Enrico Weigelt
<we...@metux.de> wrote:
>> we don't maintain configure;
> bad enough. an carefully hand-written configure would be much better.
Been there, done that with APACI. We ain't going back to a hand-written
configure.
AIUI, your problem is fixed if we roll with current autoconf and libtool
versions. I've been using ac 2.59 and lt 1.5.10 for 2.1.x releases - do
they work for you out-of-the-box? I don't know of any particular reason
why we shouldn't do so for new releases of 2.0 as well. (I think the only
reason against lt 1.5.x is that it requires a C++ compiler which throws AIX
and other barebones systems for a curve - don't know if that was fixed...)
HTH. -- justin
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* André Malo <nd...@perlig.de> wrote:
<snip>
> > With this mentality we will never get something better.
> > Such software doesnt simply fall from the heaven.
>
> Sure. We get a better httpd.
Yes, of course.
Software doesn't get built from source by magic. Either people
to this completely by hand or we have a good buildsystem which
does this automatically.
For me as a distributor/firmware vendor and maintainer of hundreds
of different systems, it is absolutely important that the build
process is *reliable* - without manual interaction. Tons of features
are quite uninteresting. And they're almost irrelevant if the
principle things are unreliable.
Autoconf is not able to provide this.
So such an buildsystem *will* make apache httpd better, and thousands
of other projects currently still hacking w/ autoconf too.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by André Malo <nd...@perlig.de>.
* Enrico Weigelt wrote:
> * Paul Querna <ch...@force-elite.com> wrote:
> > We are the httpd server project, not the autoconf
> > replacement project.
>
> With this mentality we will never get something better.
> Such software doesnt simply fall from the heaven.
Sure. We get a better httpd.
nd
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Andrew Stribblehill <ad...@debian.org>.
Quoting Enrico Weigelt <we...@metux.de> (2004-12-14 04:50:36 GMT):
> * Patrick Welche <pr...@newn.cam.ac.uk> wrote:
>
> <snip>
> > Is part of the problem automake avoidance? AFAIR httpd just uses
> No, autoconf is bad enough, automake will make it even worse.
>
> Dont expect apache to remain in so many distros if you switch
> to automake and bring distributor's life ten steps nearer to hell.
That's pure, undiluted FUD, and you know it.
--
SOUTH UTSIRE FORTIES
SOUTHERLY OR SOUTHWESTERLY 6 TO GALE 8, VEERING NORTHWESTERLY 4 OR 5
IN NORTH LATER. OCCASIONAL RAIN. MODERATE OR GOOD
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Patrick Welche <pr...@newn.cam.ac.uk> wrote:
<snip>
> Is part of the problem automake avoidance? AFAIR httpd just uses
No, autoconf is bad enough, automake will make it even worse.
Dont expect apache to remain in so many distros if you switch
to automake and bring distributor's life ten steps nearer to hell.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Enrico Weigelt <we...@metux.de> wrote:
<snip>
> I've got a fully automated distro builder system which could do nightly
> builds in a wide range of environments (currently only linux, but different
> kind of libc, other libs, features, etc) completely by itself and run
> some test programs over it. If someone could supply such test programs,
> I could set up an completely automated test environment for apache.
Forgot to say: this absolutely requires apache to be reliably
crosscompilable.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:20 PM 12/16/2004, Enrico Weigelt wrote:
>* William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>> +1 for the RM to use latest and greatest 2.5.x.
>
>Great, but it still doesn't solve such fatal problems as the grep bug.
>And autoconf is not really debuggable for folks who are not really
>autoconf-experts ...
>
>I'd suggest going away from it and writing the build stuff by hand.
>If it would be accepted, I'd be the first volunteer doing that.
Been there, done that.
Bill
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
Hi,
> >I think Joe's proposed bumping up to a mandatory autoconf 2.5x (for everyone)
> >because we keep getting nailed on autoconf 2.13 bugs. That's goodness.
>
> +1 for the RM to use latest and greatest 2.5.x.
Great, but it still doesn't solve such fatal problems as the grep bug.
And autoconf is not really debuggable for folks who are not really
autoconf-experts ...
I'd suggest going away from it and writing the build stuff by hand.
If it would be accepted, I'd be the first volunteer doing that.
<snip>
> I would like to see ALOT of feedback to current-testers or dev
> or even apache-modules of the alpha before declaring first beta.
Apropos testers: has there any work been done for completely automated
build- and run tests ?
I've got a fully automated distro builder system which could do nightly
builds in a wide range of environments (currently only linux, but different
kind of libc, other libs, features, etc) completely by itself and run
some test programs over it. If someone could supply such test programs,
I could set up an completely automated test environment for apache.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Andy Armstrong <an...@apache.org> wrote:
> Enrico Weigelt wrote:
> >yeah, and then users have to repair broken ./configure scripts
> >again and again.
>
> Really? How often does this actually happen? My experiences with
> autoconf have been pretty good down the years and they get better as
> people get better at using it.
For me: almost every day.
One of my main jobs is to build customized distros for small systems.
Evryting has to be crosscompiled (and so sysrooted). More than 50%
of the autoshit-based packages have to be fixed to get it working.
Apache is one of those packages requiring an extensive huge amount of work.
> It's certainly not beyond criticism -
> it's a sprawling and somewhat non-obvious metalanguage for a developer
> to learn for a start - but it works OK.
yeah, a chomsky-0 language, with about 90% of the files laying around
on your harddisk being silent part of the code ...
really great thing.
> >Well, at this point we have no need to use autoconf time wasting
> >autoconf anylonger. Instead we should maintain config stuff
> >carefully by hand - I'd volounteer for this job.
>
> Did we just go through a time warp? I thought we did this a month ago
> and decided it wasn't going to happen.
Yeah, since these month I had to spend whole days for fixing (not really
repairing) bugs in autoconf's spitout.
Using autoconf is really unproductive. Fixing broken stuff all over the
time eats up more resources than writing evrything by hand.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Andy Armstrong <an...@apache.org>.
Enrico Weigelt wrote:
> yeah, and then users have to repair broken ./configure scripts
> again and again.
Really? How often does this actually happen? My experiences with
autoconf have been pretty good down the years and they get better as
people get better at using it. It's certainly not beyond criticism -
it's a sprawling and somewhat non-obvious metalanguage for a developer
to learn for a start - but it works OK.
> Well, at this point we have no need to use autoconf time wasting
> autoconf anylonger. Instead we should maintain config stuff
> carefully by hand - I'd volounteer for this job.
Did we just go through a time warp? I thought we did this a month ago
and decided it wasn't going to happen.
--
Andy Armstrong, hexten.net
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Greg Stein <gs...@lyra.org> wrote:
<snip>
> pffft. Ease up on the veto there. Users don't need autoconf or
> libtool. The RM generates those files during the release process.
yeah, and then users have to repair broken ./configure scripts
again and again.
Well, at this point we have no need to use autoconf time wasting
autoconf anylonger. Instead we should maintain config stuff
carefully by hand - I'd volounteer for this job.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 14, 2004 at 03:58:42AM -0600, William A. Rowe, Jr. wrote:
> At 03:33 AM 12/14/2004, Justin Erenkrantz wrote:
> >On Tue, Dec 14, 2004 at 03:20:26AM -0600, William A. Rowe, Jr. wrote:
> >>
> >> Seriously, we could target only latest-n-greatest, but that
> >> goes against the grain of many participants.
> >
> >I think we should be much stricter for the releases we make and rather
> >leninent at buildconf-time.
> >
> >I think Joe's proposed bumping up to a mandatory autoconf 2.5x (for everyone)
> >because we keep getting nailed on autoconf 2.13 bugs. That's goodness.
>
> +1 for the RM to use latest and greatest 2.5.x.
>
> -1 veto for a 2.0.x release to require autoconf 2.5.x for these
> users who are trying to do a minor upgrade, if they are doing their
> own autoconf 2.13 config.
pffft. Ease up on the veto there. Users don't need autoconf or
libtool. The RM generates those files during the release process.
> >And, I think we should enforce libtool 1.5.10 for any future
> >release that we produce (i.e. in httpd-dist/tools/releasecheck.sh).
> >If a developer has anything above libtool 1.3, it'll work (for
> >some definition of 'work') - but they're on their own if they run
> >into problems.
>
> This is open source, if it breaks they get both parts. This is
> no different. HOWEVER - I'm -1 veto on any config changes that
> require such 'recent' versions. Suggesting this is the best
> version to use is sufficient.
For *who* ??? For developers using source from version control, then
the most recent should be fine. For people using tarballs, it is
totally irrelevant.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Glenn Strauss <gs...@gluelogic.com>.
On Tue, Dec 14, 2004 at 03:58:42AM -0600, William A. Rowe, Jr. wrote:
> I would like to see ALOT of feedback to current-testers or dev
> or even apache-modules of the alpha before declaring first beta.
> Once beta - we should be very adverse to API changes - our module
> authors will want to fix once and be done. Or should we just
> trash the idea of alphas since not enough people are testing?
> Heck, while we are at it, lets just declare it GA.
>
> The alpha better work for a good number of folks before we go
> to beta. Then ya - as you say, the oddball kernel/distro issues
> will start popping up and be fixed pretty easily before GA.
A brief reminder of what Paul brought up, and I agree with:
Corporate project managers need a better sense of the release
schedule before they build test-time into their schedules.
I am not asking for hard-and-fast release dates, because httpd
is released when it is ready and not on artificial deadlines.
A completely open-ended release date -- as is currently the case --
is all but ignored by project managers. Why spend time testing
something that is not going to be released for maybe another year
and will probably change immensely between now and then?
However, if releases were aimed for every, say, 6 months, with
a tag and semi-freeze two months prior, then I think we would see
a lot more testing by corporate users (who aren't already very
involved in this list) on those tags.
Cheers,
Glenn
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:33 AM 12/14/2004, Justin Erenkrantz wrote:
>On Tue, Dec 14, 2004 at 03:20:26AM -0600, William A. Rowe, Jr. wrote:
>>
>> Seriously, we could target only latest-n-greatest, but that
>> goes against the grain of many participants.
>
>I think we should be much stricter for the releases we make and rather
>leninent at buildconf-time.
>
>I think Joe's proposed bumping up to a mandatory autoconf 2.5x (for everyone)
>because we keep getting nailed on autoconf 2.13 bugs. That's goodness.
+1 for the RM to use latest and greatest 2.5.x.
-1 veto for a 2.0.x release to require autoconf 2.5.x for these
users who are trying to do a minor upgrade, if they are doing their
own autoconf 2.13 config.
>And, I think we should enforce libtool 1.5.10 for any future
>release that we produce (i.e. in httpd-dist/tools/releasecheck.sh).
>If a developer has anything above libtool 1.3, it'll work (for
>some definition of 'work') - but they're on their own if they run
>into problems.
This is open source, if it breaks they get both parts. This is
no different. HOWEVER - I'm -1 veto on any config changes that
require such 'recent' versions. Suggesting this is the best
version to use is sufficient.
>Of course, if we posted 2.1.2 as a 'public' beta, then we could
>start to get feedback if the ac2.59/lt1.5.10 combo breaks anyone.
Yup - and getting stronger -0.5 sense that we want to gunnie pig
our users with our problems this early.
I would like to see ALOT of feedback to current-testers or dev
or even apache-modules of the alpha before declaring first beta.
Once beta - we should be very adverse to API changes - our module
authors will want to fix once and be done. Or should we just
trash the idea of alphas since not enough people are testing?
Heck, while we are at it, lets just declare it GA.
The alpha better work for a good number of folks before we go
to beta. Then ya - as you say, the oddball kernel/distro issues
will start popping up and be fixed pretty easily before GA.
Bill
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Dec 14, 2004 at 03:20:26AM -0600, William A. Rowe, Jr. wrote:
> Of course we could do that.
>
> However, it's entirely against the first principal of httpd,
> which is that this project builds against more old and crufty
> operating systems installs than most utilities, sans 'cat' :)
>
> Seriously, we could target only latest-n-greatest, but that
> goes against the grain of many participants.
I think we should be much stricter for the releases we make and rather
leninent at buildconf-time.
I think Joe's proposed bumping up to a mandatory autoconf 2.5x (for everyone)
because we keep getting nailed on autoconf 2.13 bugs. That's goodness. And,
I think we should enforce libtool 1.5.10 for any future release that we
produce (i.e. in httpd-dist/tools/releasecheck.sh). If a developer has
anything above libtool 1.3, it'll work (for some definition of 'work') - but
they're on their own if they run into problems.
Of course, if we posted 2.1.2 as a 'public' beta, then we could start to get
feedback if the ac2.59/lt1.5.10 combo breaks anyone. =) -- justin
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:08 AM 12/13/2004, Patrick Welche wrote:
>Is part of the problem automake avoidance? AFAIR httpd just uses
>autoconf and libtool. The other thing is that now that libtool
>has a LT_PREREQ (VERSION) macro, one could set that and no longer
>maintain the special httpd distributed version and support for
>all sorts of old and crufty versions of libtool..
Of course we could do that.
However, it's entirely against the first principal of httpd,
which is that this project builds against more old and crufty
operating systems installs than most utilities, sans 'cat' :)
Seriously, we could target only latest-n-greatest, but that
goes against the grain of many participants.
Bill
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Mon, Dec 13, 2004 at 09:20:41AM +0100, Enrico Weigelt wrote:
> * Paul Querna <ch...@force-elite.com> wrote:
>
> <snip>
> > You aren't. I agree auto* sucks, but there isn't a viable alternative
> > that works today.
>
> Well, I've tried to aquire helpers for such a project for years,
> in dozens of other projects. But the only ones who were at least
> thinking about it were the xouvert folks.
>
> > We are the httpd server project, not the autoconf
> > replacement project.
> With this mentality we will never get something better.
> Such software doesnt simply fall from the heaven.
Is part of the problem automake avoidance? AFAIR httpd just uses
autoconf and libtool. The other thing is that now that libtool
has a LT_PREREQ (VERSION) macro, one could set that and no longer
maintain the special httpd distributed version and support for
all sorts of old and crufty versions of libtool..
Cheers,
Patrick
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Paul Querna <ch...@force-elite.com> wrote:
<snip>
> You aren't. I agree auto* sucks, but there isn't a viable alternative
> that works today.
Well, I've tried to aquire helpers for such a project for years,
in dozens of other projects. But the only ones who were at least
thinking about it were the xouvert folks.
> We are the httpd server project, not the autoconf
> replacement project.
With this mentality we will never get something better.
Such software doesnt simply fall from the heaven.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Paul Querna <ch...@force-elite.com>.
Enrico Weigelt wrote:
<snip>
> I dont count the days of autoconf-trouble anylonger - i'm counting
> the days when autoconfs really works, there're just a few.
>
>
> I've written down some concepts for an universal crossplatform
> compiling/building toolkit, which also supports crosscompiling and
> sysroot'ing as fundamental concepts and abstracts from platform
> or toolchain specific stuff (ie. universal parameter set for common
> things like compiler options, pathes, etc, etc).
>
> I really cant understand why it seems that I'm the first one really
> working on that ...
>
You aren't. I agree auto* sucks, but there isn't a viable alternative
that works today. We are the httpd server project, not the autoconf
replacement project.
-Paul
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
* Jeff Trawick <tr...@gmail.com> wrote:
<snip>
> we don't maintain configure;
bad enough. an carefully hand-written configure would be much better.
> it is autogenerated; any fixes need to be
> in the input files; it looks like the portion you had to modify comes
> from libtool sources, not from Apache httpd sources; have you tried
you probably meant autoconf ...
> installing a later libtool and running buildconf to regenerate
> configure?
yes, tried it. but configure remains exactly the same.
IMHO automake+frieds are a really bad joke - scripts for creating
scripts, which somehow create scripts for building software in
mysterious ways ... completely indeterministic. not really the
incarnation of reliability.
I dont count the days of autoconf-trouble anylonger - i'm counting
the days when autoconfs really works, there're just a few.
I've written down some concepts for an universal crossplatform
compiling/building toolkit, which also supports crosscompiling and
sysroot'ing as fundamental concepts and abstracts from platform
or toolchain specific stuff (ie. universal parameter set for common
things like compiler options, pathes, etc, etc).
I really cant understand why it seems that I'm the first one really
working on that ...
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, 7 Dec 2004 21:53:07 +0100, Enrico Weigelt <we...@metux.de> wrote:
>
> here's a patch against httpd-2.0.49 which fixes the broken
> configure script.
we don't maintain configure; it is autogenerated; any fixes need to be
in the input files; it looks like the portion you had to modify comes
from libtool sources, not from Apache httpd sources; have you tried
installing a later libtool and running buildconf to regenerate
configure?
[PATCH] fixing broken gnu ld (mis)detection problem
Posted by Enrico Weigelt <we...@metux.de>.
Hi folks,
here's a patch against httpd-2.0.49 which fixes the broken
configure script. I'm happy enough that I now have at least *one*
working version and I'm relly too lazy to go in deeper autoconf
torture, so the one who's responsible for ./configure should
fix it all versions.
Life could be so easy without autoshit!
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
yet another autoconf horrow story (Problem w/ apache-2.0.52 + php-4.3.9: unresolved symbol ap_loaded_modules)
Posted by Enrico Weigelt <we...@metux.de>.
After days end days of debugging the undebuggable (=autoshit),
i've found out, that configure doens't recognize my GNU ld as an
GNU ld and so disables shared libraries silently.
This ended up in libtool generating only static libraries instead
of shared objects.
Passing --with-gnu-ld didn't have any little influence on that.
I've trashed it to use $EGREP (which was detected properly) and now
evryting works fine: .so's are created and third-party modules
(ie php4) can be loaded properly.
This dawm autoshit again has costed three days of work for me.
And still it has dozens of problems (ie apxs is completely unsusable
for sysroot builds)
We really, really go away from it.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------