Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45464A03.60204@haxent.com.br>
Date: Mon, 30 Oct 2006 15:52:51 -0300
From: Davi Arnaut <davi@haxent.com.br>
MIME-Version: 1.0
To: Justin Erenkrantz <justin@erenkrantz.com>
Cc: dev@apr.apache.org
Subject: Re: [patch] bogus libtool file in APRUTIL_EXPORT_LIBS
References: <45436CE7.8070608@haxent.com.br>
	 <5c902b9e0610292235q2bfee23ar320b01e395509f5a@mail.gmail.com>
	 <4545F445.3080004@haxent.com.br>
 <5c902b9e0610300830n5b557047udb35f7bc881e2f5e@mail.gmail.com>
In-Reply-To: <5c902b9e0610300830n5b557047udb35f7bc881e2f5e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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:

ALL_LDFLAGS  = $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS)

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:

http://pkgconfig.freedesktop.org/wiki/


> 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 @@
 libdir="${exec_prefix}/lib"
 includedir="${prefix}/include/apr-${APRUTIL_MAJOR_VERSION}"

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

diff -uNr apr-util/lib/pkgconfig/apr-util-1.pc
apr-util-patched/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
-liconv
 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