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...@bellsouth.net> on 2001/05/16 19:11:26 UTC
libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
libaprutil.la has all of the expat code in it because we put `find
. -name '*.lo'` in libaprutil.la.
libexpat.la has the expat code too, of course.
apr-util sets APRUTIL_EXPORT_LIBS to tell the app to link with
libexpat.la in addition to libaprutil.la, but of course that isn't
needed since libaprutil.la includes the necessary objects.
Does anybody care how the duplication is resolved? We can keep the
expat code out of libaprutil.la or keep libexpat.la out of
APRUTIL_EXPORT_LIBS.
(On most platforms this isn't an issue but we get duplicate symbol
warnings on OS/390.)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Thu, May 17, 2001 at 07:52:29AM -0400, Jeff Trawick wrote:
> "Roy T. Fielding" <fi...@ebuilt.com> writes:
>
> > My opinion is that expat should not be included in apr-util
> > because it is not dependent on apr or apr-util. It should be
> > a --with-expat option instead.
>
> Let me make sure I understand you. Are you saying
>
> 1) don't ship expat source code with apr-util...
>
> if you have expat on your system maybe we'll find it and otherwise
> you can point to it with --with-expat
>
> if you don't have expat on your system, then apr-util won't expose
> the apr_xml wrappers and mod_dav won't build either
>
> or simply
>
> 2) keep the expat objects out of libaprutil.la; then, our existing
> logic to look for a previously-installed expat, or a new
> --with-expat option, can put your previously-installed libexpat.la
> in APRUTIL_EXPORT_LIBS instead of building our own copy and putting
> that libexpat.la in APRUTIL_EXPORT_LIBS
I meant (1), but I've committed something that will do (2) because
I'm too lazy to move it out of apr-util.
....Roy
Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
Posted by Jeff Trawick <tr...@bellsouth.net>.
"Roy T. Fielding" <fi...@ebuilt.com> writes:
> My opinion is that expat should not be included in apr-util
> because it is not dependent on apr or apr-util. It should be
> a --with-expat option instead.
Let me make sure I understand you. Are you saying
1) don't ship expat source code with apr-util...
if you have expat on your system maybe we'll find it and otherwise
you can point to it with --with-expat
if you don't have expat on your system, then apr-util won't expose
the apr_xml wrappers and mod_dav won't build either
or simply
2) keep the expat objects out of libaprutil.la; then, our existing
logic to look for a previously-installed expat, or a new
--with-expat option, can put your previously-installed libexpat.la
in APRUTIL_EXPORT_LIBS instead of building our own copy and putting
that libexpat.la in APRUTIL_EXPORT_LIBS
?
Choice #2 could be implemented by piping the find output into "grep -v
expat/lib", sort of like
Index: Makefile.in
===================================================================
RCS file: /home/cvspublic/apr-util/Makefile.in,v
retrieving revision 1.30
diff -u -r1.30 Makefile.in
--- Makefile.in 2001/04/12 01:37:33 1.30
+++ Makefile.in 2001/05/17 11:51:17
@@ -45,7 +45,7 @@
$(LIBTOOL) --mode=install cp $(TARGET_LIB) $(libdir)
$(TARGET_LIB):
- @objects="`find $(SUBDIRS) -name '*.@so_ext@'`" ; \
+ @objects="`find $(SUBDIRS) -name '*.@so_ext@' | grep -v expat/lib`" ; \
$(LINK) @lib_target@
delete-exports:
There seem to be other spots were we search for the .lo files...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
Which is why I said it should be a --with-expat option. apr-util is
also dependent on apr.
....Roy
On Wed, May 16, 2001 at 03:40:30PM -0500, William A. Rowe, Jr. wrote:
> Huh... other way around, apr-util is dependent on expat or it cannot
> build our apr-util/xml/apr_xml.c source.
>
> Bill
>
> ----- Original Message -----
> From: "Roy T. Fielding" <fi...@ebuilt.com>
> To: "Jeff Trawick" <tr...@bellsouth.net>
> Cc: <de...@apr.apache.org>
> Sent: Wednesday, May 16, 2001 2:17 PM
> Subject: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
>
>
> > My opinion is that expat should not be included in apr-util
> > because it is not dependent on apr or apr-util. It should be
> > a --with-expat option instead.
> >
> > ....Roy
> >
> >
Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
Huh... other way around, apr-util is dependent on expat or it cannot
build our apr-util/xml/apr_xml.c source.
Bill
----- Original Message -----
From: "Roy T. Fielding" <fi...@ebuilt.com>
To: "Jeff Trawick" <tr...@bellsouth.net>
Cc: <de...@apr.apache.org>
Sent: Wednesday, May 16, 2001 2:17 PM
Subject: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
> My opinion is that expat should not be included in apr-util
> because it is not dependent on apr or apr-util. It should be
> a --with-expat option instead.
>
> ....Roy
>
>
Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
My opinion is that expat should not be included in apr-util
because it is not dependent on apr or apr-util. It should be
a --with-expat option instead.
....Roy