On 10/30/06, Davi Arnaut <[EMAIL PROTECTED]> wrote:
Justin Erenkrantz wrote:
> On 10/28/06, Davi Arnaut <[EMAIL PROTECTED]> 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.
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. =)
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
