apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: [patch] bogus libtool file in APRUTIL_EXPORT_LIBS
Date Mon, 30 Oct 2006 18:52:51 GMT
Justin Erenkrantz wrote:
> On 10/30/06, Davi Arnaut <davi@haxent.com.br> wrote:
>> Justin Erenkrantz wrote:
>>> On 10/28/06, Davi Arnaut <davi@haxent.com.br> wrote:
>>>> Add the expat libtool file to the LT_LDFLAGS variable to avoid placing a
>>>> libtool file path onto LDFLAGS (pkg-config --libs apr-util-1).
>>> AFAICT, we don't ever use LT_LDFLAGS with apr-util, so we won't use
>>> the .la file when linking.  So, won't that break something?  -- justin
>> But apr-util uses apr_rules.mk (from apr) which places the LT_LDFLAGS
>> the on the libtool link command (you may confirm it by looking at apr's
>> configure.in).
> No, AFAICT, APR-util doesn't export LT_LDFLAGS.  So, the value that is
> set in the m4 would never be used anywhere else.  You are right in
> that APR-util uses the apr_rules.mk, but there is no place that the
> new value would be exported or to have knowledge that LT_LDFLAGS's .la
> specification would override the -lexpat definition in LIBS.

LT_LDFLAGS is only used within apr-util and no -lexpat is added to the
libtool link command. The .la files are not changed whatsoever.

Also, since we are using APRUTIL_EXPORT_LIBS to export -lexpat:


LINK         = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS)
$(COMPILE) -version-info 2:7:2 $(ALL_LDFLAGS) -o $@

I've actually tested it.

>> Current behavior is broken because it will place a .la file path on the
>> LDFLAGS for non-libtool compiles, as APRUTIL_EXPORT_LIBS is also used
>> when in the apr-util.pc.in file. e.g.:
>> /Users/davi/svn/apr-util $ pkg-config --libs apr-util-1
>> /Users/davi/svn/apr-util/xml/expat/lib/libexpat.la -L/tmp/apu/lib
>> -L/opt/local/lib -laprutil-1 -lsqlite3 -liconv -lapr-1 -lpthread
>> When compiling:
>> /Users/davi/svn/apr-util $ gcc -o foo test.c `pkg-config --cflags --libs
>> apr-util-1`
>> /usr/bin/ld: /Users/davi/svn/apr-util/xml/expat/lib/libexpat.la bad
>> magic number (not a Mach-O file)
>> collect2: ld returned 1 exit status
> Well, you probably should be using libtool to link not gcc.  =)

No, libtool does not make sense for the application I'm working on.
Probably even less because pkg-config was meant to be used this way :P

Look at the example given on the first paragraph of the pkg-config page:


> My concern is that this patch would break because we would not be
> using the .la file when we have libtool (which is the common case) and
> we certainly shouldn't be specifying -lexpat and the .la file at the
> same time either at the link line...  -- justin

Differences between the patched and trunk versions:

/tmp $ diff -uNr apr-util/ apr-util-patched/
diff -uNr apr-util/bin/apu-1-config apr-util-patched/bin/apu-1-config
--- apr-util/bin/apu-1-config   2006-10-30 14:26:01.000000000 -0300
+++ apr-util-patched/bin/apu-1-config   2006-10-30 15:30:24.000000000 -0300
@@ -27,7 +27,7 @@

-LIBS="-lsqlite3 /Users/davi/svn/apr-util/xml/expat/lib/libexpat.la -liconv"
+LIBS="-lsqlite3 -lexpat -liconv"

diff -uNr apr-util/lib/pkgconfig/apr-util-1.pc
--- apr-util/lib/pkgconfig/apr-util-1.pc        2006-10-30
14:25:58.000000000 -0300
+++ apr-util-patched/lib/pkgconfig/apr-util-1.pc        2006-10-30
15:30:21.000000000 -0300
@@ -9,5 +9,5 @@
 Version: 1.3.0
 # assume that apr-util requires libapr of same major version
 Requires: apr-1
-Libs: -L${libdir} -laprutil-${APRUTIL_MAJOR_VERSION} -lsqlite3
/Users/davi/svn/apr-util/xml/expat/lib/libexpat.la -liconv
+Libs: -L${libdir} -laprutil-${APRUTIL_MAJOR_VERSION} -lsqlite3 -lexpat
 Cflags: -I${includedir}

The libaprutil-1.la (patched) dependence:

dependency_libs=' -L/Users/davi/svn/apr-util/xml/expat/lib -lsqlite3
/tmp/coco/lib/libexpat.la /usr/lib/libiconv.la
/opt/local/lib/libapr-1.la -lpthread'

This /User.. path is also used whithout the patch, it should be fixed too ?

Davi Arnaut

View raw message