Re: [PATCH] fixing broken gnu ld (mis)detection problem
* Andy Armstrong <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
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
* Greg Stein <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
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
At 10:20 PM 12/16/2004, Enrico Weigelt wrote: >* William A. Rowe, Jr. <[EMAIL PROTECTED]> 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
* Enrico Weigelt <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
* William A. Rowe, Jr. <[EMAIL PROTECTED]> 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. > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
* Joe Orton <[EMAIL PROTECTED]> wrote:
> 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: [EMAIL PROTECTED]
cellphone: +49 174 7066481
-
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-
Re: [PATCH] fixing broken gnu ld (mis)detection problem
On Tue, Dec 14, 2004 at 06:58:06PM +0100, Enrico Weigelt wrote:
> * Joe Orton <[EMAIL PROTECTED]> 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
* Joe Orton <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
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
Quoting Enrico Weigelt <[EMAIL PROTECTED]> (2004-12-14 04:50:36 GMT): > * Patrick Welche <[EMAIL PROTECTED]> wrote: > > > > 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
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
* Patrick Welche <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
* André Malo <[EMAIL PROTECTED]> wrote: > > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
--On Monday, December 13, 2004 5:29 AM +0100 Enrico Weigelt <[EMAIL PROTECTED]> 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
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
On Tue, Dec 14, 2004 at 09:00:58AM +, 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
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
On Mon, Dec 13, 2004 at 03:35:38PM -0800, Justin Erenkrantz wrote: > --On Monday, December 13, 2004 5:29 AM +0100 Enrico Weigelt > <[EMAIL PROTECTED]> 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: [PATCH] fixing broken gnu ld (mis)detection problem
On Mon, Dec 13, 2004 at 09:20:41AM +0100, Enrico Weigelt wrote: > * Paul Querna <[EMAIL PROTECTED]> wrote: > > > > 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
* Enrico Weigelt wrote: > * Paul Querna <[EMAIL PROTECTED]> 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
* Paul Querna <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
Enrico Weigelt wrote: 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
* Jeff Trawick <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: [PATCH] fixing broken gnu ld (mis)detection problem
On Tue, 7 Dec 2004 21:53:07 +0100, Enrico Weigelt <[EMAIL PROTECTED]> 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?
