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/21 09:44:43 UTC
Re: cvs commit: httpd-2.0 configure.in
I don't understand this one. This is what the exports were for. Why this
change?
[ we have time to fix now, thankfully... the beta seemed a bit rushed today
with all the last minute changes ]
Cheers,
-g
On Thu, Dec 21, 2000 at 01:27:47AM -0000, rbb@locus.apache.org wrote:
> rbb 00/12/20 17:27:47
>
> Modified: . configure.in
> Log:
> Actually link apr-util's .a file, instead of relying on libtool. We may
> want to change this later, but right now, we want a single binary that
> has every function it requires.
>
> Revision Changes Path
> 1.106 +1 -1 httpd-2.0/configure.in
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/configure.in,v
> retrieving revision 1.105
> retrieving revision 1.106
> diff -u -r1.105 -r1.106
> --- configure.in 2000/12/20 16:43:30 1.105
> +++ configure.in 2000/12/21 01:27:46 1.106
> @@ -174,7 +174,7 @@
>
> dnl AP_LIB_DIRS specifies the additional libs from srclib/ that we need
> dnl AP_LIBS specifies the actual libraries. note we have some required libs.
> -AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/libaprutil.la"
> +AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/.libs/libaprutil.a"
>
> if test "$apache_need_expat" = "yes"; then
> AP_LIB_DIRS="$AP_LIB_DIRS expat-lite"
>
>
>
--
Greg Stein, http://www.lyra.org/
BeOS shared lib problems (was: Re: cvs commit: httpd-2.0 configure.in)
Posted by Greg Stein <gs...@lyra.org>.
What is this "human intervention" that you mention?
And are you saying that BeOS has no shared libraries? It isn't like we'd be
loading libaprutil.so dynamically... I'd expect the loader to automatically
pull that in when the executable is loaded.
Cheers,
-g
On Fri, Dec 22, 2000 at 01:17:03PM -0000, David Reid wrote:
> The issue applies on other platforms that have crazy loaders (BeOS is one
> for sure) which need to have all symbols defined at load-time. Apr-util
> doesn't presently build without human intervention on BeOS and will only
> build as a static library. When the .la is included in the final link for
> httpd it fails unless I add in the static library by hand as it's static. :(
>
> If Sascha can fix this (and I'm betting he can...) then it'll be cool.
>
> david
> ----- Original Message -----
> From: "Greg Stein" <gs...@lyra.org>
> To: <ne...@apache.org>
> Sent: Friday, December 22, 2000 8:44 AM
> Subject: Re: cvs commit: httpd-2.0 configure.in
>
>
> > The symbol might not be in httpd, but the first that happens when httpd is
> > loaded, is the loader will also pull in the libaprutil.so file. The
> symbols
> > (such as ap_bucket_make) will then be available within the process (to
> > Apache itself and to other modules).
> >
> > Is there a requirement to static-link Apache, rather than depend on shared
> > libraries?
> >
> > (there *is* a config switch to force aprutil to only build a static lib,
> but
> > I'd like to know why we need to do that)
> >
> > Cheers,
> > -g
> >
> > On Thu, Dec 21, 2000 at 06:20:06AM -0800, rbb@covalent.net wrote:
> > >
> > > > I don't understand this one. This is what the exports were for. Why
> this
> > > > change?
> > >
> > > Because that's not the way libtool works. If you use the .la file, it
> is
> > > always treated as a shared library. That is just the way that libtool
> > > works, if I understand the docs. Tell you what, back out the change,
> and
> > > re-build to code. Then, do
> > >
> > > nm ./httpd | grep ap_bucket_make
> > >
> > > Whenever I did that, I found that ./httpd didn't have that symbol.
> > >
> > > Ryan
> > >
> > > >
> > > > [ we have time to fix now, thankfully... the beta seemed a bit rushed
> today
> > > > with all the last minute changes ]
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > On Thu, Dec 21, 2000 at 01:27:47AM -0000, rbb@locus.apache.org wrote:
> > > > > rbb 00/12/20 17:27:47
> > > > >
> > > > > Modified: . configure.in
> > > > > Log:
> > > > > Actually link apr-util's .a file, instead of relying on libtool.
> We may
> > > > > want to change this later, but right now, we want a single binary
> that
> > > > > has every function it requires.
> > > > >
> > > > > Revision Changes Path
> > > > > 1.106 +1 -1 httpd-2.0/configure.in
> > > > >
> > > > > Index: configure.in
> > > > >
> ===================================================================
> > > > > RCS file: /home/cvs/httpd-2.0/configure.in,v
> > > > > retrieving revision 1.105
> > > > > retrieving revision 1.106
> > > > > diff -u -r1.105 -r1.106
> > > > > --- configure.in 2000/12/20 16:43:30 1.105
> > > > > +++ configure.in 2000/12/21 01:27:46 1.106
> > > > > @@ -174,7 +174,7 @@
> > > > >
> > > > > dnl AP_LIB_DIRS specifies the additional libs from srclib/ that
> we need
> > > > > dnl AP_LIBS specifies the actual libraries. note we have some
> required libs.
> > > > > -AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/libaprutil.la"
> > > > > +AP_LIBS="srclib/pcre/libpcre.la
> srclib/apr-util/.libs/libaprutil.a"
> > > > >
> > > > > if test "$apache_need_expat" = "yes"; then
> > > > > AP_LIB_DIRS="$AP_LIB_DIRS expat-lite"
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Greg Stein, http://www.lyra.org/
> > > >
> > > >
> > >
> > >
> > >
> ____________________________________________________________________________
> ___
> > > Ryan Bloom rbb@apache.org
> > > 406 29th St.
> > > San Francisco, CA 94131
> >
> > --------------------------------------------------------------------------
> -----
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 configure.in
Posted by David Reid <dr...@jetnet.co.uk>.
The issue applies on other platforms that have crazy loaders (BeOS is one
for sure) which need to have all symbols defined at load-time. Apr-util
doesn't presently build without human intervention on BeOS and will only
build as a static library. When the .la is included in the final link for
httpd it fails unless I add in the static library by hand as it's static. :(
If Sascha can fix this (and I'm betting he can...) then it'll be cool.
david
----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>
To: <ne...@apache.org>
Sent: Friday, December 22, 2000 8:44 AM
Subject: Re: cvs commit: httpd-2.0 configure.in
> The symbol might not be in httpd, but the first that happens when httpd is
> loaded, is the loader will also pull in the libaprutil.so file. The
symbols
> (such as ap_bucket_make) will then be available within the process (to
> Apache itself and to other modules).
>
> Is there a requirement to static-link Apache, rather than depend on shared
> libraries?
>
> (there *is* a config switch to force aprutil to only build a static lib,
but
> I'd like to know why we need to do that)
>
> Cheers,
> -g
>
> On Thu, Dec 21, 2000 at 06:20:06AM -0800, rbb@covalent.net wrote:
> >
> > > I don't understand this one. This is what the exports were for. Why
this
> > > change?
> >
> > Because that's not the way libtool works. If you use the .la file, it
is
> > always treated as a shared library. That is just the way that libtool
> > works, if I understand the docs. Tell you what, back out the change,
and
> > re-build to code. Then, do
> >
> > nm ./httpd | grep ap_bucket_make
> >
> > Whenever I did that, I found that ./httpd didn't have that symbol.
> >
> > Ryan
> >
> > >
> > > [ we have time to fix now, thankfully... the beta seemed a bit rushed
today
> > > with all the last minute changes ]
> > >
> > > Cheers,
> > > -g
> > >
> > > On Thu, Dec 21, 2000 at 01:27:47AM -0000, rbb@locus.apache.org wrote:
> > > > rbb 00/12/20 17:27:47
> > > >
> > > > Modified: . configure.in
> > > > Log:
> > > > Actually link apr-util's .a file, instead of relying on libtool.
We may
> > > > want to change this later, but right now, we want a single binary
that
> > > > has every function it requires.
> > > >
> > > > Revision Changes Path
> > > > 1.106 +1 -1 httpd-2.0/configure.in
> > > >
> > > > Index: configure.in
> > > >
===================================================================
> > > > RCS file: /home/cvs/httpd-2.0/configure.in,v
> > > > retrieving revision 1.105
> > > > retrieving revision 1.106
> > > > diff -u -r1.105 -r1.106
> > > > --- configure.in 2000/12/20 16:43:30 1.105
> > > > +++ configure.in 2000/12/21 01:27:46 1.106
> > > > @@ -174,7 +174,7 @@
> > > >
> > > > dnl AP_LIB_DIRS specifies the additional libs from srclib/ that
we need
> > > > dnl AP_LIBS specifies the actual libraries. note we have some
required libs.
> > > > -AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/libaprutil.la"
> > > > +AP_LIBS="srclib/pcre/libpcre.la
srclib/apr-util/.libs/libaprutil.a"
> > > >
> > > > if test "$apache_need_expat" = "yes"; then
> > > > AP_LIB_DIRS="$AP_LIB_DIRS expat-lite"
> > > >
> > > >
> > > >
> > >
> > > --
> > > Greg Stein, http://www.lyra.org/
> > >
> > >
> >
> >
> >
____________________________________________________________________________
___
> > Ryan Bloom rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
>
> --------------------------------------------------------------------------
-----
>
> --
> Greg Stein, http://www.lyra.org/
>
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> > > > That's great, as long as the library is available to be loaded. If you do
> > > > a make clean immediately after running make install, the library isn't
> > > > there anymore. If we install it when we run make install, then I believe
> > > > we will need to modify the LD_LIBRARY_PATH to point to the correct
> > > > directory.
>
> Why aren't we installing aprutil? If we install Apache, then we really need
> to install aprutil, too!
Because the Makefile for aprutil doesn't have a make install, and even if
it did, where would it go, and how would you direct it there?
> And no, we wouldn't (usually) need LD_LIBRARY_PATH. That is one of the
> things that libtool helps us with. It will pass the -rpath switch during a
> link so that the app knows where to pick up the library. If the platform
> doesn't support -rpath, then libtool does some other neat hand-waving to
> make it work.
Does that mean that we have to install the library in the same relative
path as it was built in? For example, if the relative path to the library
at build time is srclib/apr-util does that mean that it needs to be
installed in srclib/apr-util, or can it be installed in libs/?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 22, 2000 at 08:38:58AM -0800, rbb@covalent.net wrote:
>
> > > > The symbol might not be in httpd, but the first that happens when httpd is
> > > > loaded, is the loader will also pull in the libaprutil.so file. The symbols
> > > > (such as ap_bucket_make) will then be available within the process (to
> > > > Apache itself and to other modules).
> > >
> > > That's great, as long as the library is available to be loaded. If you do
> > > a make clean immediately after running make install, the library isn't
> > > there anymore. If we install it when we run make install, then I believe
> > > we will need to modify the LD_LIBRARY_PATH to point to the correct
> > > directory.
Why aren't we installing aprutil? If we install Apache, then we really need
to install aprutil, too!
And no, we wouldn't (usually) need LD_LIBRARY_PATH. That is one of the
things that libtool helps us with. It will pass the -rpath switch during a
link so that the app knows where to pick up the library. If the platform
doesn't support -rpath, then libtool does some other neat hand-waving to
make it work.
> > What exactly is the purpose of building apr-util in the
> > Apache 2.0 context? Is Apache the sole user of the library
> > or do we install the library for consumption of other
> > applications?
>
> Currently, Apache is the only user of this library, just like APR. I
Nah... SVN will be using it quite soon. We just haven't plugged it in yet
and started using it. I've gotta shift over the URI and XML handling stuff,
too. But I also intend to use the apr_dbm stuff, the MD5/SHA1 hashing, and
the base64 encoding.
> personally think it is overkill _right now_ to try to build these
> dynamically. Let's get Apache building and get all the bugs ironed out,
> then we can get the build environment setup for shared libraries.
The solution you're looking for is to pass --disable-shared to the
RUN_SUBDIR_CONFIG_NOW() for aprutil. Then continue to link against the .la.
That is a cleaner workaround than using .libs.
But we still need to install aprutil when Apache is installed. Not doing
that is just borken :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> > > The symbol might not be in httpd, but the first that happens when httpd is
> > > loaded, is the loader will also pull in the libaprutil.so file. The symbols
> > > (such as ap_bucket_make) will then be available within the process (to
> > > Apache itself and to other modules).
> >
> > That's great, as long as the library is available to be loaded. If you do
> > a make clean immediately after running make install, the library isn't
> > there anymore. If we install it when we run make install, then I believe
> > we will need to modify the LD_LIBRARY_PATH to point to the correct
> > directory.
>
> What exactly is the purpose of building apr-util in the
> Apache 2.0 context? Is Apache the sole user of the library
> or do we install the library for consumption of other
> applications?
Currently, Apache is the only user of this library, just like APR. I
personally think it is overkill _right now_ to try to build these
dynamically. Let's get Apache building and get all the bugs ironed out,
then we can get the build environment setup for shared libraries.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 22 Dec 2000 rbb@covalent.net wrote:
>
> > The symbol might not be in httpd, but the first that happens when httpd is
> > loaded, is the loader will also pull in the libaprutil.so file. The symbols
> > (such as ap_bucket_make) will then be available within the process (to
> > Apache itself and to other modules).
>
> That's great, as long as the library is available to be loaded. If you do
> a make clean immediately after running make install, the library isn't
> there anymore. If we install it when we run make install, then I believe
> we will need to modify the LD_LIBRARY_PATH to point to the correct
> directory.
What exactly is the purpose of building apr-util in the
Apache 2.0 context? Is Apache the sole user of the library
or do we install the library for consumption of other
applications?
- Sascha
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> > The symbol might not be in httpd, but the first that happens when httpd is
> > loaded, is the loader will also pull in the libaprutil.so file. The symbols
> > (such as ap_bucket_make) will then be available within the process (to
> > Apache itself and to other modules).
>
> That's great, as long as the library is available to be loaded. If you do
> a make clean immediately after running make install, the library isn't
> there anymore. If we install it when we run make install, then I believe
> we will need to modify the LD_LIBRARY_PATH to point to the correct
> directory.
BTW, the make clean is exactly what binbuild.sh does when you build a
distribution, and that is how I found this problem.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> The symbol might not be in httpd, but the first that happens when httpd is
> loaded, is the loader will also pull in the libaprutil.so file. The symbols
> (such as ap_bucket_make) will then be available within the process (to
> Apache itself and to other modules).
That's great, as long as the library is available to be loaded. If you do
a make clean immediately after running make install, the library isn't
there anymore. If we install it when we run make install, then I believe
we will need to modify the LD_LIBRARY_PATH to point to the correct
directory.
> Is there a requirement to static-link Apache, rather than depend on shared
> libraries?
1.3 always used static libraries. One of the reasons for this, is that it
is a real PITA to keep libraries in sync. There are also security
concerns. There are people who believe that it is less secure to have
anything loaded into the server at run-time. Those are people who tend to
build without mod_so. I am not saying I necessarily agree with these
people, just that I have heard that concern raised.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by Greg Stein <gs...@lyra.org>.
The symbol might not be in httpd, but the first that happens when httpd is
loaded, is the loader will also pull in the libaprutil.so file. The symbols
(such as ap_bucket_make) will then be available within the process (to
Apache itself and to other modules).
Is there a requirement to static-link Apache, rather than depend on shared
libraries?
(there *is* a config switch to force aprutil to only build a static lib, but
I'd like to know why we need to do that)
Cheers,
-g
On Thu, Dec 21, 2000 at 06:20:06AM -0800, rbb@covalent.net wrote:
>
> > I don't understand this one. This is what the exports were for. Why this
> > change?
>
> Because that's not the way libtool works. If you use the .la file, it is
> always treated as a shared library. That is just the way that libtool
> works, if I understand the docs. Tell you what, back out the change, and
> re-build to code. Then, do
>
> nm ./httpd | grep ap_bucket_make
>
> Whenever I did that, I found that ./httpd didn't have that symbol.
>
> Ryan
>
> >
> > [ we have time to fix now, thankfully... the beta seemed a bit rushed today
> > with all the last minute changes ]
> >
> > Cheers,
> > -g
> >
> > On Thu, Dec 21, 2000 at 01:27:47AM -0000, rbb@locus.apache.org wrote:
> > > rbb 00/12/20 17:27:47
> > >
> > > Modified: . configure.in
> > > Log:
> > > Actually link apr-util's .a file, instead of relying on libtool. We may
> > > want to change this later, but right now, we want a single binary that
> > > has every function it requires.
> > >
> > > Revision Changes Path
> > > 1.106 +1 -1 httpd-2.0/configure.in
> > >
> > > Index: configure.in
> > > ===================================================================
> > > RCS file: /home/cvs/httpd-2.0/configure.in,v
> > > retrieving revision 1.105
> > > retrieving revision 1.106
> > > diff -u -r1.105 -r1.106
> > > --- configure.in 2000/12/20 16:43:30 1.105
> > > +++ configure.in 2000/12/21 01:27:46 1.106
> > > @@ -174,7 +174,7 @@
> > >
> > > dnl AP_LIB_DIRS specifies the additional libs from srclib/ that we need
> > > dnl AP_LIBS specifies the actual libraries. note we have some required libs.
> > > -AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/libaprutil.la"
> > > +AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/.libs/libaprutil.a"
> > >
> > > if test "$apache_need_expat" = "yes"; then
> > > AP_LIB_DIRS="$AP_LIB_DIRS expat-lite"
> > >
> > >
> > >
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
linking libraries (was: Re: cvs commit: httpd-2.0 configure.in)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 21, 2000 at 07:26:17PM +0100, Sascha Schumann wrote:
> > That might work for libmain, if I could figure out our build system to
> > implement it. But, for apr-util, which must be usable outside of Apache
> > as either a shared library or a static one, a convenience library isn't an
> > option.
>
> Why cannot we create a two step process for apr-util then?
>
> 1. Create a convenience library.
>
> 2. Create a normal libtool library, pulling in the
> convenience library.
>
> Apache could then use the lib produced in step 1, while the
> result from step 2 would be installed (or whatever you are
> doing with it).
This would be good, in general. I can easily see other libtool-based apps
wanting a convenience library.
In other words, APR(UTIL) would build three things:
1) classic .a object archive
2) .so shared library
3) libtool convenience library
Sascha: what is the right magic for doing this?
[ I'd also like to know because I think it might be useful within SVN ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
linking libraries (was: Re: cvs commit: httpd-2.0 configure.in)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 21, 2000 at 07:26:17PM +0100, Sascha Schumann wrote:
> > That might work for libmain, if I could figure out our build system to
> > implement it. But, for apr-util, which must be usable outside of Apache
> > as either a shared library or a static one, a convenience library isn't an
> > option.
>
> Why cannot we create a two step process for apr-util then?
>
> 1. Create a convenience library.
>
> 2. Create a normal libtool library, pulling in the
> convenience library.
>
> Apache could then use the lib produced in step 1, while the
> result from step 2 would be installed (or whatever you are
> doing with it).
This would be good, in general. I can easily see other libtool-based apps
wanting a convenience library.
In other words, APR(UTIL) would build three things:
1) classic .a object archive
2) .so shared library
3) libtool convenience library
Sascha: what is the right magic for doing this?
[ I'd also like to know because I think it might be useful within SVN ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
choice of libtool? (was: Re: cvs commit: httpd-2.0 configure.in)
Posted by Greg Stein <gs...@lyra.org>.
Keep libtool.
We shouldn't be attempting to figure out how to build shared libs on N
different platforms out there.
In this particular case, Sascha has indicated we can use "convenience"
libraries to solve our particular issue. I don't see any problem with that.
And yes, apps could go into .libs and fetch stuff, but it isn't ideal for
the reasons Sascha mentions; but he even provides a way to solve that if we
truly deem it to be a problem.
... in other words, we just have a few changes to make. That is a lot less
than tossing out libtool and redeveloping an alternate solution.
Cheers,
-g
On Thu, Dec 21, 2000 at 11:12:52AM -0800, rbb@covalent.net wrote:
>
> IMO, libtool is not a good choice for Apache. I realize that it is very
> late in the game to say this, but many people have said it before. The
> fact is that we have spent more time fighting libtool recently than we
> spend doing any other single thing.
>
> Everytime this argument comes up, we discuss it and although most of us
> agree that we severly dislike libtool, we end up using it anyway. I think
> that is unacceptable. I don't care if this delays the beta more, I want
> to solve this once and for all.
>
> So, I am asking for a simple vote. If we vote to keep libtool, then
> somebody will also need to volunteer to keep it working, because I am sick
> of fighting our build environment just to be told I did it wrong. If we
> vote to remove libtool, then I will volunteer to port the old build system
> to Apache 2.0.
>
> So, would people please vote about whether we want to keep libtool or not.
>
> My own vote is that we get rid of libtool.
>
> Ryan
>
> On Thu, 21 Dec 2000, Sascha Schumann wrote:
>
> > > Because the whole argument for using libtool for apr-util, was that we
> > > could use the .libs/ libraries very easily, and they will work for all
> > > programs, whether they use libtool or not. If that isn't true, then we
> > > should stop using libtool all together, and go to the simpler setup that
> > > APR is currently using.
> >
> > For programs which don't use libtool directly, apr-util could
> > add a mechanism to install itself into a temporary directory.
> > The directory would contain the final shared and/or static
> > libraries. Otherwise, you rely on an implementation detail
> > which can easily change. For example, on certain platforms,
> > libtool uses "_libs" instead of ".libs".
> >
> > This could also be used by Apache, if you dislike the
> > two-step mechanism.
> >
> > - Sascha
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
> So, I am asking for a simple vote. If we vote to keep libtool, then
> somebody will also need to volunteer to keep it working, because I am sick
> of fighting our build environment just to be told I did it wrong.
I've volunteered for that job before. Come to me, state the
problem, and we will work out a solution.
> My own vote is that we get rid of libtool.
+1 for doing the Right Thing(tm) and outsourcing non-core
business.
- Sascha
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
IMO, libtool is not a good choice for Apache. I realize that it is very
late in the game to say this, but many people have said it before. The
fact is that we have spent more time fighting libtool recently than we
spend doing any other single thing.
Everytime this argument comes up, we discuss it and although most of us
agree that we severly dislike libtool, we end up using it anyway. I think
that is unacceptable. I don't care if this delays the beta more, I want
to solve this once and for all.
So, I am asking for a simple vote. If we vote to keep libtool, then
somebody will also need to volunteer to keep it working, because I am sick
of fighting our build environment just to be told I did it wrong. If we
vote to remove libtool, then I will volunteer to port the old build system
to Apache 2.0.
So, would people please vote about whether we want to keep libtool or not.
My own vote is that we get rid of libtool.
Ryan
On Thu, 21 Dec 2000, Sascha Schumann wrote:
> > Because the whole argument for using libtool for apr-util, was that we
> > could use the .libs/ libraries very easily, and they will work for all
> > programs, whether they use libtool or not. If that isn't true, then we
> > should stop using libtool all together, and go to the simpler setup that
> > APR is currently using.
>
> For programs which don't use libtool directly, apr-util could
> add a mechanism to install itself into a temporary directory.
> The directory would contain the final shared and/or static
> libraries. Otherwise, you rely on an implementation detail
> which can easily change. For example, on certain platforms,
> libtool uses "_libs" instead of ".libs".
>
> This could also be used by Apache, if you dislike the
> two-step mechanism.
>
> - Sascha
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
> Because the whole argument for using libtool for apr-util, was that we
> could use the .libs/ libraries very easily, and they will work for all
> programs, whether they use libtool or not. If that isn't true, then we
> should stop using libtool all together, and go to the simpler setup that
> APR is currently using.
For programs which don't use libtool directly, apr-util could
add a mechanism to install itself into a temporary directory.
The directory would contain the final shared and/or static
libraries. Otherwise, you rely on an implementation detail
which can easily change. For example, on certain platforms,
libtool uses "_libs" instead of ".libs".
This could also be used by Apache, if you dislike the
two-step mechanism.
- Sascha
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> > That might work for libmain, if I could figure out our build system to
> > implement it. But, for apr-util, which must be usable outside of Apache
> > as either a shared library or a static one, a convenience library isn't an
> > option.
>
> Why cannot we create a two step process for apr-util then?
>
> 1. Create a convenience library.
>
> 2. Create a normal libtool library, pulling in the
> convenience library.
>
> Apache could then use the lib produced in step 1, while the
> result from step 2 would be installed (or whatever you are
> doing with it).
Because the whole argument for using libtool for apr-util, was that we
could use the .libs/ libraries very easily, and they will work for all
programs, whether they use libtool or not. If that isn't true, then we
should stop using libtool all together, and go to the simpler setup that
APR is currently using.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
> That might work for libmain, if I could figure out our build system to
> implement it. But, for apr-util, which must be usable outside of Apache
> as either a shared library or a static one, a convenience library isn't an
> option.
Why cannot we create a two step process for apr-util then?
1. Create a convenience library.
2. Create a normal libtool library, pulling in the
convenience library.
Apache could then use the lib produced in step 1, while the
result from step 2 would be installed (or whatever you are
doing with it).
- Sascha
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> > > I don't understand this one. This is what the exports were for. Why this
> > > change?
> >
> > Because that's not the way libtool works. If you use the .la file, it is
> > always treated as a shared library. That is just the way that libtool
> > works, if I understand the docs.
>
> I'm not sure why you ignored my comment last time, but you
> are looking for libtool convenience libraries (which don't
> behave like shared libraries). Those allow you to do this
> job cleanly without relying on implementation details.
That might work for libmain, if I could figure out our build system to
implement it. But, for apr-util, which must be usable outside of Apache
as either a shared library or a static one, a convenience library isn't an
option. I didn't ignore your message either. I looked through our
build system, and couldn't see an easy way to turn on a convenience
library for a single directory, so I just did something that I know would
work.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0 configure.in
Posted by Sascha Schumann <sa...@schumann.cx>.
On Thu, 21 Dec 2000 rbb@covalent.net wrote:
>
> > I don't understand this one. This is what the exports were for. Why this
> > change?
>
> Because that's not the way libtool works. If you use the .la file, it is
> always treated as a shared library. That is just the way that libtool
> works, if I understand the docs.
I'm not sure why you ignored my comment last time, but you
are looking for libtool convenience libraries (which don't
behave like shared libraries). Those allow you to do this
job cleanly without relying on implementation details.
- Sascha
Re: cvs commit: httpd-2.0 configure.in
Posted by rb...@covalent.net.
> I don't understand this one. This is what the exports were for. Why this
> change?
Because that's not the way libtool works. If you use the .la file, it is
always treated as a shared library. That is just the way that libtool
works, if I understand the docs. Tell you what, back out the change, and
re-build to code. Then, do
nm ./httpd | grep ap_bucket_make
Whenever I did that, I found that ./httpd didn't have that symbol.
Ryan
>
> [ we have time to fix now, thankfully... the beta seemed a bit rushed today
> with all the last minute changes ]
>
> Cheers,
> -g
>
> On Thu, Dec 21, 2000 at 01:27:47AM -0000, rbb@locus.apache.org wrote:
> > rbb 00/12/20 17:27:47
> >
> > Modified: . configure.in
> > Log:
> > Actually link apr-util's .a file, instead of relying on libtool. We may
> > want to change this later, but right now, we want a single binary that
> > has every function it requires.
> >
> > Revision Changes Path
> > 1.106 +1 -1 httpd-2.0/configure.in
> >
> > Index: configure.in
> > ===================================================================
> > RCS file: /home/cvs/httpd-2.0/configure.in,v
> > retrieving revision 1.105
> > retrieving revision 1.106
> > diff -u -r1.105 -r1.106
> > --- configure.in 2000/12/20 16:43:30 1.105
> > +++ configure.in 2000/12/21 01:27:46 1.106
> > @@ -174,7 +174,7 @@
> >
> > dnl AP_LIB_DIRS specifies the additional libs from srclib/ that we need
> > dnl AP_LIBS specifies the actual libraries. note we have some required libs.
> > -AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/libaprutil.la"
> > +AP_LIBS="srclib/pcre/libpcre.la srclib/apr-util/.libs/libaprutil.a"
> >
> > if test "$apache_need_expat" = "yes"; then
> > AP_LIB_DIRS="$AP_LIB_DIRS expat-lite"
> >
> >
> >
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------