You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@covalent.net> on 2001/08/24 06:31:57 UTC
.libs/httpd
why is the installed httpd different from .libs/httpd?
% ls -l ~/ap/prefork/bin/httpd
-rwxr-xr-x 1 dougm dougm 4318551 Aug 23 21:11
% ls -l .libs/httpd
-rwxr-xr-x 1 dougm dougm 4318583 Aug 23 21:21 .libs/httpd*
i normally don't "make install" everytime i'm working on a change and run
httpd out of the build directory. now it seems i have to to install get a
proper httpd. what gives?
Re: .libs/httpd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 24 August 2001 14:58, Greg Stein wrote:
> On Fri, Aug 24, 2001 at 02:42:30PM -0700, Ryan Bloom wrote:
> >...
> > Because it is absolutely bogus that I have to choose whether EVERYTHING
> > in the build is static or dynamic. I should be able to configure APR to
> > be built as a static lib, but still have shared modules.
>
> Then you should have stopped the "one libtool for everybody" push. As long
> as we have a single libtool, and that thing is responsible for building
> static and/or dynamic outputs, then we can only build in the way specified
> by that one libtool.
I completely disagree. I should be able to pass a set of flags to the libtool line,
and have those flags determine how libtools works. That was how it worked when
libtool and ltconfig were separate packages.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: .libs/httpd
Posted by Sascha Schumann <sa...@schumann.cx>.
> Actually, there is nothing wrong with that -- especially with
> libtool 1.4, it makes sense to have only libtool script,
^ one
> because it is not preconfigured to build certain types of
> object files. It can be used by all included libraries,
> because you can tell libtool on the command-line whether it
> should build an object file which is suitable for an archive
> or a DSO.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
Re: .libs/httpd
Posted by Sascha Schumann <sa...@schumann.cx>.
> Then you should have stopped the "one libtool for everybody" push.
Actually, there is nothing wrong with that -- especially with
libtool 1.4, it makes sense to have only libtool script,
because it is not preconfigured to build certain types of
object files. It can be used by all included libraries,
because you can tell libtool on the command-line whether it
should build an object file which is suitable for an archive
or a DSO.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
Re: .libs/httpd
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 02:42:30PM -0700, Ryan Bloom wrote:
>...
> Because it is absolutely bogus that I have to choose whether EVERYTHING
> in the build is static or dynamic. I should be able to configure APR to be built
> as a static lib, but still have shared modules.
Then you should have stopped the "one libtool for everybody" push. As long
as we have a single libtool, and that thing is responsible for building
static and/or dynamic outputs, then we can only build in the way specified
by that one libtool.
Then you could build APR statically, and the rest of the system shared. Of
course, this also assumes that httpd-2.0/configure has the right set of
switches to prepare such a system.
But without the configure switches, you have no hope to do it anyways. So
you aren't even at a libtool problem yet.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: .libs/httpd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 24 August 2001 14:40, Greg Stein wrote:
> On Fri, Aug 24, 2001 at 01:50:06PM -0700, Ryan Bloom wrote:
> > On Friday 24 August 2001 13:51, Greg Stein wrote:
> > > On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote:
> >
> >...
> >
> > > > Please don't do that. Passing --disable-shared is what caused the
> > > > shared modules to stop working.
> > >
> > > Apache should be able to work as one big monolithic executable. Shared
> > > modules should still be able to work because Apache would still have
> > > DSO loading capabilities.
> >
> > But as I said, libtool sucks. Basically, libtool 1.4 has combined
> > ltconfig and libtool into one executable. If you pass --disable-shared
> > to the configure step, the libtool is built in such a way, that it can no
> > longer create shared libraries.
>
> That has nothing to do with libtool. You configured the system to build
> things as static libraries. Why would you suddenly expected the *output* of
> that configuration to be able to build shared libs?
>
> Even so, an external module could be built as a shared lib, and loaded by
> that monolithic Apache. And hey... maybe somebody built a monolithic Apache
> *specifically* to disallow new modules.
>
> So I'm not sure why your undies are all in a bunch about libtool and the
> --disable-shared switch.
Because it is absolutely bogus that I have to choose whether EVERYTHING
in the build is static or dynamic. I should be able to configure APR to be built
as a static lib, but still have shared modules.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: .libs/httpd
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 01:50:06PM -0700, Ryan Bloom wrote:
> On Friday 24 August 2001 13:51, Greg Stein wrote:
> > On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote:
>...
> > > Please don't do that. Passing --disable-shared is what caused the shared
> > > modules to stop working.
> >
> > Apache should be able to work as one big monolithic executable. Shared
> > modules should still be able to work because Apache would still have DSO
> > loading capabilities.
>
> But as I said, libtool sucks. Basically, libtool 1.4 has combined ltconfig and
> libtool into one executable. If you pass --disable-shared to the configure
> step, the libtool is built in such a way, that it can no longer create shared
> libraries.
That has nothing to do with libtool. You configured the system to build
things as static libraries. Why would you suddenly expected the *output* of
that configuration to be able to build shared libs?
Even so, an external module could be built as a shared lib, and loaded by
that monolithic Apache. And hey... maybe somebody built a monolithic Apache
*specifically* to disallow new modules.
So I'm not sure why your undies are all in a bunch about libtool and the
--disable-shared switch.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: .libs/httpd
Posted by Sascha Schumann <sa...@schumann.cx>.
> But as I said, libtool sucks. Basically, libtool 1.4 has
> combined ltconfig and libtool into one executable. If you pass
> --disable-shared to the configure step, the libtool is built in
> such a way, that it can no longer create shared libraries.
A user should not directly temper with the way libtool is
created, because it is unlikely that she understands the
impact of doing so. I would suggest to set enable_shared and
enable_static to yes before AC_PROG_LIBTOOL is run, so that
the build framework can choose what libtool does during
compile-time. This would facilitate supporting a flag
--enable-static-apr or something similar which acts locally
instead of bogusly setting one global flag.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
Re: .libs/httpd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 24 August 2001 13:51, Greg Stein wrote:
> On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote:
> > On Friday 24 August 2001 00:33, Greg Stein wrote:
> > > On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote:
> >
> >...
> >
> > > > libuncooltool. i didn't realize libapr was now linked as a shared
> > > > library. that explains everything.
> > >
> > > You could probably pass --disable-shared at Apache's config line. Of
> > > course, then *everything* would be built statically and you'd get a big
> > > ass blob of an executable :-)
> >
> > Please don't do that. Passing --disable-shared is what caused the shared
> > modules to stop working.
>
> Apache should be able to work as one big monolithic executable. Shared
> modules should still be able to work because Apache would still have DSO
> loading capabilities.
But as I said, libtool sucks. Basically, libtool 1.4 has combined ltconfig and
libtool into one executable. If you pass --disable-shared to the configure
step, the libtool is built in such a way, that it can no longer create shared
libraries.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: .libs/httpd
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 08:27:57AM -0700, Ryan Bloom wrote:
> On Friday 24 August 2001 00:33, Greg Stein wrote:
> > On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote:
>...
> > > libuncooltool. i didn't realize libapr was now linked as a shared
> > > library. that explains everything.
> >
> > You could probably pass --disable-shared at Apache's config line. Of
> > course, then *everything* would be built statically and you'd get a big ass
> > blob of an executable :-)
>
> Please don't do that. Passing --disable-shared is what caused the shared
> modules to stop working.
Apache should be able to work as one big monolithic executable. Shared
modules should still be able to work because Apache would still have DSO
loading capabilities.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: .libs/httpd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 24 August 2001 00:33, Greg Stein wrote:
> On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote:
> > On Thu, 23 Aug 2001, Roy T. Fielding wrote:
> > > As I recall, libtool modifies the runtime library path within the exec
> > > when it installs the file, or something like that.
> >
> > libuncooltool. i didn't realize libapr was now linked as a shared
> > library. that explains everything.
>
> You could probably pass --disable-shared at Apache's config line. Of
> course, then *everything* would be built statically and you'd get a big ass
> blob of an executable :-)
Please don't do that. Passing --disable-shared is what caused the shared
modules to stop working.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: .libs/httpd
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 12:15:17AM -0700, Doug MacEachern wrote:
> On Thu, 23 Aug 2001, Roy T. Fielding wrote:
>
> > As I recall, libtool modifies the runtime library path within the exec
> > when it installs the file, or something like that.
>
> libuncooltool. i didn't realize libapr was now linked as a shared
> library. that explains everything.
You could probably pass --disable-shared at Apache's config line. Of course,
then *everything* would be built statically and you'd get a big ass blob of
an executable :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: .libs/httpd
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 08:27:05AM -0700, Ryan Bloom wrote:
> On Friday 24 August 2001 00:15, Doug MacEachern wrote:
> > On Thu, 23 Aug 2001, Roy T. Fielding wrote:
> > > As I recall, libtool modifies the runtime library path within the exec
> > > when it installs the file, or something like that.
> >
> > libuncooltool. i didn't realize libapr was now linked as a shared
> > library. that explains everything.
>
> That's because libtool SUCKS!
Has nothing to do with libtool. That is just a convenient scapegoat.
APR can/should be a shared library. Should have been a long time ago, but we
didn't have installation running for it, so we made it a static library.
That was turned off recently, making things as they should be.
What are you blaming libtool for? Can you state the specific problem?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: .libs/httpd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 24 August 2001 08:50, Victor J. Orlikowski wrote:
> > > libuncooltool. i didn't realize libapr was now linked as a shared
> > > library. that explains everything.
> >
> > That's because libtool SUCKS! This was all a part of my patches to
> > make shared modules work with libtool. We could potentially configure
> > APR to always be a static lib, but I'm not sure how hard that would be to
> > do.
>
> Believe that we've had this thread before. ;(
> I agree; libtool is being a pain. Now, what do we want to do about it
> (which was not resolved the last time this discussion came
> up - ISTR it was a discussion in London, last year.)?
It is actually possible to configure Apache to not use libtool, but running
./configure --disable-libtool
I haven't kept that logic up to date though.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: .libs/httpd
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 24 Aug 2001, Ryan Bloom wrote:
> That's because libtool SUCKS! This was all a part of my patches to
> make shared modules work with libtool. We could potentially configure
> APR to always be a static lib, but I'm not sure how hard that would be to
> do.
i don't mind libapr being shared, i just had no idea it was shared when i
was having that problem last night. now that i know, symlinking install
(*.so) to the build tree works fine.
Re: .libs/httpd
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 24 August 2001 00:15, Doug MacEachern wrote:
> On Thu, 23 Aug 2001, Roy T. Fielding wrote:
> > As I recall, libtool modifies the runtime library path within the exec
> > when it installs the file, or something like that.
>
> libuncooltool. i didn't realize libapr was now linked as a shared
> library. that explains everything.
That's because libtool SUCKS! This was all a part of my patches to
make shared modules work with libtool. We could potentially configure
APR to always be a static lib, but I'm not sure how hard that would be to
do.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: .libs/httpd
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 23 Aug 2001, Roy T. Fielding wrote:
> As I recall, libtool modifies the runtime library path within the exec
> when it installs the file, or something like that.
libuncooltool. i didn't realize libapr was now linked as a shared
library. that explains everything.
Re: .libs/httpd
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> It should be placed via make install by "libtool --mode=install" now.
> I'd have to see if the act of installation changes the file - I only
> thought it helped copy the right file. If it changes it, blech.
As I recall, libtool modifies the runtime library path within the exec
when it installs the file, or something like that.
....Roy
Re: .libs/httpd
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 23, 2001 at 09:31:57PM -0700, Doug MacEachern wrote:
> why is the installed httpd different from .libs/httpd?
>
> % ls -l ~/ap/prefork/bin/httpd
> -rwxr-xr-x 1 dougm dougm 4318551 Aug 23 21:11
>
> % ls -l .libs/httpd
> -rwxr-xr-x 1 dougm dougm 4318583 Aug 23 21:21 .libs/httpd*
>
> i normally don't "make install" everytime i'm working on a change and run
> httpd out of the build directory. now it seems i have to to install get a
> proper httpd. what gives?
That's odd.
Does .libs/httpd even work?
It should be placed via make install by "libtool --mode=install" now.
I'd have to see if the act of installation changes the file - I only
thought it helped copy the right file. If it changes it, blech.
-- justin