You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/12/11 03:41:18 UTC
Re: cvs commit: apr Makefile.in
jerenkrantz@apache.org writes:
> jerenkrantz 01/12/10 17:42:10
>
> Modified: . Makefile.in
> Log:
> If we tell libtool what our link dependencies are (by including them when
> we build libapr.la), it will remember the dependencies for us. So, if a
> third-party (say httpd, flood, SVN, etc.) want to link against libapr.la,
> they don't need to worry about the library dependencies that are currently
> stored in EXTRA_LIBS et al.
>
> This has been tested with libtool-1.4. Further testing and integration
> needs to be done. But, this could simplify our build system a bit w.r.t.
> library dependencies.
Shortly after these commits I get the following on a system with libtool
1.3.4. Coincidence?
> libtool: link: error: cannot link shared libraries into libtool
> libraries
> make[3]: *** [libaprutil.la] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr Makefile.in
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Dec 11, 2001 at 11:19:17AM -0800, Justin Erenkrantz wrote:
> On Tue, Dec 11, 2001 at 01:59:23PM -0500, Jeff Trawick wrote:
> > uhh, I trust it was by accident that you committed code without prior
> > discussion that used a feature that doesn't work on libtool < 1.4.? on
> > any platform ;)
>
> The docs for libtool suggested this trick should work for all
> platforms.
>
> http://sources.redhat.com/autobook/autobook/autobook_77.html
>
> There was no mention of it not working on AIX. =) But, given all
> of the DSO problems, I'm not surprised.
>
> > The system refuses to load httpd because it doesn't know how to find
> > libaprutil. I would guess that the library search path that libtool
> > records in the executable file is somehow hosed, but I have not had a
> > chance to look into it.
>
> Are the libraries installed? I know that libtool is supposed to do
> some rewriting of the paths when it "installs" the executable.
> Perhaps that isn't happening? -- justin
>
When libtool installs things we often see that banner that goes by saying
"to complete this installation you need to run libtool --finish $prefix/lib"
Which most people tend to ignore, because its a no-op on Linux. Maybe it is
actually required but not performed on AIX?
Just a thought from someone who doesn't know much about libtool.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: cvs commit: apr Makefile.in
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Dec 11, 2001 at 01:59:23PM -0500, Jeff Trawick wrote:
> uhh, I trust it was by accident that you committed code without prior
> discussion that used a feature that doesn't work on libtool < 1.4.? on
> any platform ;)
The docs for libtool suggested this trick should work for all
platforms.
http://sources.redhat.com/autobook/autobook/autobook_77.html
There was no mention of it not working on AIX. =) But, given all
of the DSO problems, I'm not surprised.
> The system refuses to load httpd because it doesn't know how to find
> libaprutil. I would guess that the library search path that libtool
> records in the executable file is somehow hosed, but I have not had a
> chance to look into it.
Are the libraries installed? I know that libtool is supposed to do
some rewriting of the paths when it "installs" the executable.
Perhaps that isn't happening? -- justin
Re: cvs commit: apr Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Tue, Dec 11, 2001 at 07:17:34AM -0500, Jeff Trawick wrote:
> > Jeff Trawick <tr...@attglobal.net> writes:
> >
> > > I don't have a big problem with upgrading. Somebody needs to figure
> > > out what libtool we really require now and go fix the version checking
> > > logic in buildconf.
> >
> > I take that back. I have all sorts of failures on AIX (libtool 1.4.2)
> > this a.m. related to libtool. I think we need to back this out for
> > now and put it back in when:
>
> Okay, it's reverted. It was worth a shot. =)
uhh, I trust it was by accident that you committed code without prior
discussion that used a feature that doesn't work on libtool < 1.4.? on
any platform ;)
> > 1) we know what libtool version is required and everybody has a chance
> > to upgrade (or bug their sysops to upgrade)
>
> I believe at least libtool 1.4. There are lots of reasons to require
> 1.4.2 (Mac OS X is only supported with 1.4.2). This is just a developer
> requirement not an end-user requirement, so I think we could be fairly
> picky about our versions if we believe it'll give us a good value in
> the long-run.
no argument there
> > 2) people such as myself have at least some chance to debug why a
> > supposedly good version of libtool can't deal with the new usage on
> > a particular platform (e.g., AIX)
>
> Well, everything libtool says is DSO isn't supported on AIX.
I don't understand that statement. Give me details. Yeah, I think
libtool could do more of the work, but apparently there are various
projects which successfully use libtool for shared libraries on AIX.
There are several people hanging out on the libtool list which are
knowledgeable in both AIX shared libraries and libtool. They seemed
surprised that we had problems with Apache.
> We're
> trying our best to prove them wrong. My guess is that the dependency
> generation is turned off since they "know" that AIX has no dependency
> support. We will probably have to teach libtool about dependencies.
> Can you post the errors you were seeing? I don't have AIX, but I
> can try doing research on it time permitting. -- justin
The system refuses to load httpd because it doesn't know how to find
libaprutil. I would guess that the library search path that libtool
records in the executable file is somehow hosed, but I have not had a
chance to look into it.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr Makefile.in
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Dec 11, 2001 at 07:17:34AM -0500, Jeff Trawick wrote:
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > I don't have a big problem with upgrading. Somebody needs to figure
> > out what libtool we really require now and go fix the version checking
> > logic in buildconf.
>
> I take that back. I have all sorts of failures on AIX (libtool 1.4.2)
> this a.m. related to libtool. I think we need to back this out for
> now and put it back in when:
Okay, it's reverted. It was worth a shot. =)
> 1) we know what libtool version is required and everybody has a chance
> to upgrade (or bug their sysops to upgrade)
I believe at least libtool 1.4. There are lots of reasons to require
1.4.2 (Mac OS X is only supported with 1.4.2). This is just a developer
requirement not an end-user requirement, so I think we could be fairly
picky about our versions if we believe it'll give us a good value in
the long-run.
> 2) people such as myself have at least some chance to debug why a
> supposedly good version of libtool can't deal with the new usage on
> a particular platform (e.g., AIX)
Well, everything libtool says is DSO isn't supported on AIX. We're
trying our best to prove them wrong. My guess is that the dependency
generation is turned off since they "know" that AIX has no dependency
support. We will probably have to teach libtool about dependencies.
Can you post the errors you were seeing? I don't have AIX, but I
can try doing research on it time permitting. -- justin
Re: cvs commit: apr Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> I don't have a big problem with upgrading. Somebody needs to figure
> out what libtool we really require now and go fix the version checking
> logic in buildconf.
I take that back. I have all sorts of failures on AIX (libtool 1.4.2)
this a.m. related to libtool. I think we need to back this out for
now and put it back in when:
1) we know what libtool version is required and everybody has a chance
to upgrade (or bug their sysops to upgrade)
2) people such as myself have at least some chance to debug why a
supposedly good version of libtool can't deal with the new usage on
a particular platform (e.g., AIX)
if it turns out to be a libtool problem, then no forced upgrade
until there is a new working version
if it is our problem, then obviously it is for the person who cares
about that platform to fix and it isn't fair to hold up the change
for more than a few days
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Mon, Dec 10, 2001 at 09:41:18PM -0500, Jeff Trawick wrote:
> > Shortly after these commits I get the following on a system with libtool
> > 1.3.4. Coincidence?
>
> Probably not. ...
...
> 1) Is it possible you have --disable-shared turned on? I'm not
nope
> sure if this would affect libtool, but it might turn off
> dependency checks. All we want to do is populate the
> dependency_libs variable in libapr(util).la. Passing the
> library names at link-time seems to be the way to do it.
> In addition, these variables could also be passed on to the
> linker which could in theory barf on them when building a
> static library. I just don't know. (What OS is this?)
Linux
> 2) It is possible that the dependency generation of older
> libtools is broken. I'd suggest that the benefit of
> upgrading to this scheme (i.e. removing export_vars.sh
> and relying on libtool to handle it) is worth forcing
> developers to upgrade to whatever version has correct
> dependency handling (my guess would be libtool 1.4+).
I don't have a big problem with upgrading. Somebody needs to figure
out what libtool we really require now and go fix the version checking
logic in buildconf.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr Makefile.in
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Dec 10, 2001 at 09:41:18PM -0500, Jeff Trawick wrote:
> Shortly after these commits I get the following on a system with libtool
> 1.3.4. Coincidence?
Probably not. Well, let me explain why I think this commit is
necessary. The problem is that APR and APR-util aren't playing
very nice when you try to build packages that may not have APR in
the source tree. I'll call packages that contain APR in the source
tree to contain bundled versions (i.e. httpd). And, packages that
rely on installed copies are unbundled (i.e. SVN or flood).
Take a look at apr-util's export_vars.sh:
APRUTIL_EXPORT_LIBS="-lgdbm -ldb /home/jerenkrantz/cvs-apache/httpd-2.0/srclib/apr-util/xml/expat/lib/libexpat.la"
This file is *completely* bogus. We are indicating that they require
the source directory to build apr-util correctly (partly because I'm
using the bundled expat and httpd/flood/SVN need to link against the
right external libraries). Indicating the source dir is evil. But,
we can't also specify the prefix either because of bundling - if
it was $prefix/lib/libexpat.la, httpd-2.0 would die since apr-util
hasn't been installed yet, so libexpat.la doesn't exist. We're in
a Catch-22 here (not to mention that export_vars.sh isn't even
installed by apr-util!).
And, this is where libtool and this commit come in. libtool has
this functionality built-in. If we specify the libraries we depend
on when we build the .la file, libtool will record them and ensure
that any libtool-aware build (i.e. httpd) will link in the right
libraries without any knowledge by httpd of these dependencies. The
nice thing is that when we install the .la file via libtool, it'll
change the paths to things like a bundled expat. The uninstalled
libaprutil.la will cite $builddir/xml/expat/lib/libexpat.la and the
installed libaprutil.la will call $prefix/lib/libexpat.la. That's
exactly what we want to have happen.
So, we can remove the need for export_vars.sh and potentially
clean up APRVARS to have less stuff in it (and possibly move to
an apr-config shell script to replace APRVARS). All that a
third-party has to do is link in libapr(util).la and everything
works. IMHO, this is general goodness and we should do this.
Now, that you hopefully understand where I'm coming from, let me
postulate what may be going on:
1) Is it possible you have --disable-shared turned on? I'm not
sure if this would affect libtool, but it might turn off
dependency checks. All we want to do is populate the
dependency_libs variable in libapr(util).la. Passing the
library names at link-time seems to be the way to do it.
In addition, these variables could also be passed on to the
linker which could in theory barf on them when building a
static library. I just don't know. (What OS is this?)
2) It is possible that the dependency generation of older
libtools is broken. I'd suggest that the benefit of
upgrading to this scheme (i.e. removing export_vars.sh
and relying on libtool to handle it) is worth forcing
developers to upgrade to whatever version has correct
dependency handling (my guess would be libtool 1.4+).
Sadly, my bet is on #2.
I hope my rationale is clear. =) If not, I'll just keep
trying to make myself understood. -- justin