You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2000/12/22 23:21:23 UTC
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
On Fri, Dec 22, 2000 at 04:57:10PM -0500, greg wrote:
> Greg Stein wrote:
> >
> > I'm thinking that we want to have a
> > file describe the features it needs, then ask APR to get them for us.
> >
> > For example:
> >
> > #define APR_WANT_STDIO 1
> > #define APR_WANT_MEM_FUNCS 1
> > #define APR_WANT_STR_FUNCS 1
> > #include "apr_want.h"
> >
>
> Love the concept...don't like the timing. Can it wait until after the
> beta?
I believe the beta is indefinitely delayed. It'll be at least a week.
That said: I'm out of town Saturday thru Thursday, so I wouldn't be doing
this for a while anyways.
> I've been fighting OS/390 build problems for over a day because of the
> apr-util/.libs change.
If we reverted that change and just went against the .la again, would that
work for you? The use of .libs should never have happened.
> Sounds like it's giving David Reed some grief also.
That is also simply fixed by passing --disable-shared from the top-level
configure. Although, we should be able to work with shared libraries, so we
need to find out what his "human intervention" really means. In other words,
--disable-shared simply hides other problems that need to be fixed. By the
time that we release, we should not be using --disable-shared.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 22, 2000 at 02:27:05PM -0800, rbb@covalent.net wrote:
>
> > > I've been fighting OS/390 build problems for over a day because of the
> > > apr-util/.libs change.
> >
> > If we reverted that change and just went against the .la again, would that
> > work for you? The use of .libs should never have happened.
>
> -1. The .libs thing works, reverting it just breaks every platform
> instead of just OS/390. If you want to change to Sascha's mechanism fine,
> but you can't just back out the change.
Give me a break, Ryan. I *KNOW* that just removing that is insufficient. I'm
also testing the addition of --disable-shared to the subdir config, as I
mentioned earlier.
Sheesh.
-g
--
Greg Stein, http://www.lyra.org/
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 22, 2000 at 02:27:05PM -0800, rbb@covalent.net wrote:
>
> > > I've been fighting OS/390 build problems for over a day because of the
> > > apr-util/.libs change.
> >
> > If we reverted that change and just went against the .la again, would that
> > work for you? The use of .libs should never have happened.
>
> -1. The .libs thing works, reverting it just breaks every platform
> instead of just OS/390. If you want to change to Sascha's mechanism fine,
> but you can't just back out the change.
Give me a break, Ryan. I *KNOW* that just removing that is insufficient. I'm
also testing the addition of --disable-shared to the subdir config, as I
mentioned earlier.
Sheesh.
-g
--
Greg Stein, http://www.lyra.org/
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by rb...@covalent.net.
> > > Have a merry christmas one and all, and Ryan try and spend some time with
> > > your lovely wife will you??!!
> >
> > I'm gone to a b&b (with Kelly obviously) for the weekend, and the only
> > computer I'm bringing doesn't have a modem, so don't expect to hear from
> > me. :-)
>
> Um. Bringing a computer? It doesn't matter whether it has a modem or not. It
> shouldn't be there.
I know, but I don't have a choice. I have a book and an article I need to
work on. :-(
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 22, 2000 at 04:52:12PM -0800, rbb@covalent.net wrote:
>
> > The "manual intervention" is to add "../apr/libapr.a" to the build line to
> > get all the symbols resolved for BeOS. Doing this gives libtool a pause and
> > it only then builds the libaprutil.a library. Of course when we come to the
> > final link stage and we pass libaprutil.la it then doesn't bother adding
> > anything to the linka nd so it fails with a good number of unresolved
> > symbols and I have to then add the library manually to get it completed...
> > :(
>
> Shouldn't the change to .libs/libaprutil.a have taken care of this for
> you?
He is referring to the link step of libaprutil itself.
It shouldn't be a problem to add @APR_SOURCE_DIR@/libapr.la to the link when
we get APR libtool'd. Until that point, we can add -L@APR_SOURCE_DIR@ -lapr
to the link line. That should be an acceptable patch until APR is libtool'd.
> > Have a merry christmas one and all, and Ryan try and spend some time with
> > your lovely wife will you??!!
>
> I'm gone to a b&b (with Kelly obviously) for the weekend, and the only
> computer I'm bringing doesn't have a modem, so don't expect to hear from
> me. :-)
Um. Bringing a computer? It doesn't matter whether it has a modem or not. It
shouldn't be there.
;-)
Happy holidays,
-g
--
Greg Stein, http://www.lyra.org/
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Dec 23, 2000 at 12:38:28AM -0000, David Reid wrote:
>...
> > That is also simply fixed by passing --disable-shared from the top-level
> > configure. Although, we should be able to work with shared libraries, so we
> > need to find out what his "human intervention" really means. In other words,
> > --disable-shared simply hides other problems that need to be fixed. By the
> > time that we release, we should not be using --disable-shared.
>
> The "manual intervention" is to add "../apr/libapr.a" to the build line to
> get all the symbols resolved for BeOS. Doing this gives libtool a pause and
> it only then builds the libaprutil.a library. Of course when we come to the
> final link stage and we pass libaprutil.la it then doesn't bother adding
> anything to the linka nd so it fails with a good number of unresolved
> symbols and I have to then add the library manually to get it completed...
Hmm. I see. It is possible that it is failing the link of the shared lib.
Thus, if you disable the shared lib build, then we'd be okay for now.
We will want to put it back to dynamic library building at some point,
however.
> I'll try a build with --disbale-shared but as apache 2.0 is the first
It is in the top-level configure now. Just update from CVS and try it.
>...
> How about having a define in the process that we can set with flags to pass
> to apr-utils build? Then we can set --disable-shared for just apr-util and
> solve the problem? perhaps add it to apr's hints.m4? Just a thought.
> Don't know if it would work.
It's in there now. In the future, we could always add it only for BeOS, but
I'd think that if BeOS is just never going to get it right, then we do that
within aprutil itself. There may be some things that we can do to/with
libtool itself to make this smoother.
In any case, we'd want to localize the change within aprutil. If Apache
can't deal with a dynamic library of aprutil, there is no reason to expect
that others will.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by rb...@covalent.net.
> The "manual intervention" is to add "../apr/libapr.a" to the build line to
> get all the symbols resolved for BeOS. Doing this gives libtool a pause and
> it only then builds the libaprutil.a library. Of course when we come to the
> final link stage and we pass libaprutil.la it then doesn't bother adding
> anything to the linka nd so it fails with a good number of unresolved
> symbols and I have to then add the library manually to get it completed...
> :(
Shouldn't the change to .libs/libaprutil.a have taken care of this for
you?
> Have a merry christmas one and all, and Ryan try and spend some time with
> your lovely wife will you??!!
I'm gone to a b&b (with Kelly obviously) for the weekend, and the only
computer I'm bringing doesn't have a modem, so don't expect to hear from
me. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by David Reid <dr...@jetnet.co.uk>.
> > Love the concept...don't like the timing. Can it wait until after the
> > beta?
Yeah, the concept is a good one...
+1
> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
Know the feeling...
> > Sounds like it's giving David Reed some grief also.
sp x 50!
> That is also simply fixed by passing --disable-shared from the top-level
> configure. Although, we should be able to work with shared libraries, so
we
> need to find out what his "human intervention" really means. In other
words,
> --disable-shared simply hides other problems that need to be fixed. By the
> time that we release, we should not be using --disable-shared.
The "manual intervention" is to add "../apr/libapr.a" to the build line to
get all the symbols resolved for BeOS. Doing this gives libtool a pause and
it only then builds the libaprutil.a library. Of course when we come to the
final link stage and we pass libaprutil.la it then doesn't bother adding
anything to the linka nd so it fails with a good number of unresolved
symbols and I have to then add the library manually to get it completed...
:(
I'll try a build with --disbale-shared but as apache 2.0 is the first
version of apache on BeOS that supports dynamic libraries I don't really
want to say "sure we have the support but because of the build system and
BeOS's linker we have to build statically". Not cool.
How about having a define in the process that we can set with flags to pass
to apr-utils build? Then we can set --disable-shared for just apr-util and
solve the problem? perhaps add it to apr's hints.m4? Just a thought.
Don't know if it would work.
Have a merry christmas one and all, and Ryan try and spend some time with
your lovely wife will you??!!
:))
david
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by greg <gr...@raleigh.ibm.com>.
Greg Stein wrote:
>
> > Love the concept...don't like the timing. Can it wait until after the
> > beta?
>
> I believe the beta is indefinitely delayed. It'll be at least a week.
>
> That said: I'm out of town Saturday thru Thursday, so I wouldn't be doing
> this for a while anyways.
>
> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
>
> If we reverted that change and just went against the .la again, would that
> work for you? The use of .libs should never have happened.
>
We updated the OS/390 libtool to deal with .libs, so now we can build
fine either way. Let's just do the Right Thing here (whatever that is).
My point is that the code base seems to be less than beta quality at
present, and this sounds like a fairly big change. I'm going to start
debugging the OS/390 static page problems ASAP. What about
FreeBSD...any progress there?
Greg
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by rb...@covalent.net.
> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
>
> If we reverted that change and just went against the .la again, would that
> work for you? The use of .libs should never have happened.
-1. The .libs thing works, reverting it just breaks every platform
instead of just OS/390. If you want to change to Sascha's mechanism fine,
but you can't just back out the change.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by rb...@covalent.net.
> > I've been fighting OS/390 build problems for over a day because of the
> > apr-util/.libs change.
>
> If we reverted that change and just went against the .la again, would that
> work for you? The use of .libs should never have happened.
-1. The .libs thing works, reverting it just breaks every platform
instead of just OS/390. If you want to change to Sascha's mechanism fine,
but you can't just back out the change.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: config tests
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 28, 2000 at 06:27:43AM -0800, rbb@covalent.net wrote:
>
> > My suggestion though... let's follow the ansi/posix/unix spec and simply
> > #define WANT_APR_STDIO_H before including apr... e.g. we know what the
> > offical stdio.h should have, so if it's a matter of including stdio plus
> > stdlib plus conio on win32, then that's what the win32 port does.
>
> The problem is that it isn't just Win32. Different Unixes put different
> functions in different header files.
Exactly. And saying "WANT_APR_STDIO_H" is completely the opposite direction
of what the apr_want.h stuff is trying to do. We want *FEATURE* inclusion,
not something to say "include stdio.h for me, please". Bah. The caller can
just do that themselves.
The program enumerates the *features*, then apr_want.h gets those features
from wherever they are.
Yes, we'll probably have one called APR_WANT_STDIO meaning the "standard
I/O" features. If the platform doesn't have stdio.h, then we can punt with a
#error (cuz we certainly can't continue without the FILE type defined).
If using #error isn't sufficient, and bits of (needed) stdio can be found in
other headers, then we may need to refine the WANT symbols. e.g. WANT_PRINTF
or WANT_FILE_TYPE or whatever; then we go find those specific features.
Whatever... but APR_WANT_STDIO_H is the wrong direction.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, December 28, 2000 8:28 AM
>
> > My suggestion though... let's follow the ansi/posix/unix spec and simply
> > #define WANT_APR_STDIO_H before including apr... e.g. we know what the
> > offical stdio.h should have, so if it's a matter of including stdio plus
> > stdlib plus conio on win32, then that's what the win32 port does.
>
> The problem is that it isn't just Win32. Different Unixes
> put different functions in different header files.
Reread with s/win32 port/yourplatform port/
Yes, of course. I just don't want a bunch of individual APR_WANT_PRINTF,
nor do I want to have us invent a bunch of arbitrary groupings. Ansi spec
already went to the trouble of grouping them, and while perhaps no
platform is 100% ansi, at least it's a place to start.
Bill
RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by rb...@covalent.net.
> My suggestion though... let's follow the ansi/posix/unix spec and simply
> #define WANT_APR_STDIO_H before including apr... e.g. we know what the
> offical stdio.h should have, so if it's a matter of including stdio plus
> stdlib plus conio on win32, then that's what the win32 port does.
The problem is that it isn't just Win32. Different Unixes put different
functions in different header files.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: config tests (was: Re: cvs commit: httpd-2.0/support ...)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
This is a great idea :-)
My suggestion though... let's follow the ansi/posix/unix spec and simply
#define WANT_APR_STDIO_H before including apr... e.g. we know what the
offical stdio.h should have, so if it's a matter of including stdio plus
stdlib plus conio on win32, then that's what the win32 port does.
Refer to everything by some -very- consistent id (the spec is best) and
we should have a mission + a reasonable chance of success.
One thing that is guarenteed to screw us up, however, is the sequence of
defines and include "apr.h" ... but I know you already have a great
solution thought up :-)
Bill
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, December 22, 2000 4:21 PM
> To: new-httpd@apache.org; dev@apr.apache.org
> Subject: Re: config tests (was: Re: cvs commit: httpd-2.0/support ...)
>
>
> On Fri, Dec 22, 2000 at 04:57:10PM -0500, greg wrote:
> > Greg Stein wrote:
> > >
> > > I'm thinking that we want to have a
> > > file describe the features it needs, then ask APR to get
> them for us.
> > >
> > > For example:
> > >
> > > #define APR_WANT_STDIO 1
> > > #define APR_WANT_MEM_FUNCS 1
> > > #define APR_WANT_STR_FUNCS 1
> > > #include "apr_want.h"
> > >
> >
> > Love the concept...don't like the timing. Can it wait until
> after the
> > beta?
>
> I believe the beta is indefinitely delayed. It'll be at least a week.
>
> That said: I'm out of town Saturday thru Thursday, so I
> wouldn't be doing
> this for a while anyways.
>
> > I've been fighting OS/390 build problems for over a day
> because of the
> > apr-util/.libs change.
>
> If we reverted that change and just went against the .la
> again, would that
> work for you? The use of .libs should never have happened.
>
> > Sounds like it's giving David Reed some grief also.
>
> That is also simply fixed by passing --disable-shared from
> the top-level
> configure. Although, we should be able to work with shared
> libraries, so we
> need to find out what his "human intervention" really means.
> In other words,
> --disable-shared simply hides other problems that need to be
> fixed. By the
> time that we release, we should not be using --disable-shared.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>