You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Davi Arnaut <da...@haxent.com.br> on 2006/10/28 16:44:55 UTC
[patch] bogus libtool file in APRUTIL_EXPORT_LIBS
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).
--
Davi Arnaut
Re: [patch] bogus libtool file in APRUTIL_EXPORT_LIBS
Posted by Davi Arnaut <da...@haxent.com.br>.
Justin Erenkrantz wrote:
> On 10/30/06, Davi Arnaut <da...@haxent.com.br> wrote:
>> Justin Erenkrantz wrote:
>>> On 10/28/06, Davi Arnaut <da...@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
Re: [patch] bogus libtool file in APRUTIL_EXPORT_LIBS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/30/06, Davi Arnaut <da...@haxent.com.br> wrote:
> Justin Erenkrantz wrote:
> > On 10/28/06, Davi Arnaut <da...@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.
> 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
Re: [patch] bogus libtool file in APRUTIL_EXPORT_LIBS
Posted by Davi Arnaut <da...@haxent.com.br>.
Justin Erenkrantz wrote:
> On 10/28/06, Davi Arnaut <da...@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).
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
--
Davi Arnaut
Re: [patch] bogus libtool file in APRUTIL_EXPORT_LIBS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/28/06, Davi Arnaut <da...@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