Re: .libs/httpd
> 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
> 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
> 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
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
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
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
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
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
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
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
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: .libs/httpd
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
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
> 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
On Thu, 23 Aug 2001, Justin Erenkrantz wrote: > libtool --version? -- justin % libtool --version ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
Re: .libs/httpd
On Thu, Aug 23, 2001 at 09:47:36PM -0700, Doug MacEachern wrote: > if i edit/save filepath.c and make, everything relinks and i still have > the same problem. after 'make install', the installed binary works as > expected, as does .libs/httpd. but, change a file, run 'make', appears to > relink .libs/httpd, yet it behaves like the old version. very weird. libtool --version? -- justin
Re: .libs/httpd
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-x1 dougmdougm 4318551 Aug 23 21:11 > > % ls -l .libs/httpd > -rwxr-xr-x1 dougmdougm 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
Re: .libs/httpd
whoops, file sizes are the same, i made a change before make install again. but i still have the same problem, they are still different somehow. i had done this: make distclean cvs up buildconf configure ... && make depend && make yet somehow (note warning): (gdb) b apr_filepath_root Breakpoint 1 at 0x4003655f: file filepath.c, line 102. (gdb) c Continuing. Breakpoint 1, apr_filepath_root (rootpath=0xb774, inpath=0xb784, flags=0, p=0x825570c) at filepath.c:102 warning: Source file is more recent than executable. 102 if (**inpath == '/') (gdb) info source Current source file is filepath.c Compilation directory is /home/dougm/ap/httpd-2.0-prefork/srclib/apr/file_io/unix/ Located in /home/dougm/ap/httpd-2.0-prefork/srclib/apr/file_io/unix/filepath.c Contains 324 lines. Source language is c. Compiled with stabs debugging format. (gdb) q % ls -l /home/dougm/ap/httpd-2.0-prefork/srclib/apr/file_io/unix/filepath.c -rw-r--r--1 dougmdougm 11237 Aug 23 20:33 % wc -l /home/dougm/ap/httpd-2.0-prefork/srclib/apr/file_io/unix/filepath.c 324 % ls -l ~/ap/httpd-2.0-prefork/.libs/httpd -rwxr-xr-x1 dougmdougm 4318551 Aug 23 20:51 if i edit/save filepath.c and make, everything relinks and i still have the same problem. after 'make install', the installed binary works as expected, as does .libs/httpd. but, change a file, run 'make', appears to relink .libs/httpd, yet it behaves like the old version. very weird.
.libs/httpd
why is the installed httpd different from .libs/httpd? % ls -l ~/ap/prefork/bin/httpd -rwxr-xr-x1 dougmdougm 4318551 Aug 23 21:11 % ls -l .libs/httpd -rwxr-xr-x1 dougmdougm 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?
