You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/01/30 19:10:47 UTC
Re: [Vote] httpd 2.2.22 release
On 1/30/2012 4:02 AM, Rainer Jung wrote:
>
> We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect
> which version we have. That works for most gcc versions, but recent gcc chokes, because
> apu_version.h includes apr_version.h, which can not be found due to our setting of
> CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails.
>
> Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version
> check fixes this.
That is a bug in apu-1-config; which must include the apr-1 path in
its reported --includes (and --libs). An apu which isn't usable because
it doesn't resolve apr is worthless.
That's how all .pc and other include/lib resolvers are supposed to behave.
The same must be true for the linker.
Re: [Vote] httpd 2.2.22 release
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 12:27 PM, Rainer Jung wrote:
> On 30.01.2012 19:10, William A. Rowe Jr. wrote:
>> On 1/30/2012 4:02 AM, Rainer Jung wrote:
>>>
>>> We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect
>>> which version we have. That works for most gcc versions, but recent gcc chokes, because
>>> apu_version.h includes apr_version.h, which can not be found due to our setting of
>>> CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check
>>> fails.
>>>
>>> Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version
>>> check fixes this.
>>
>> That is a bug in apu-1-config; which must include the apr-1 path in
>> its reported --includes (and --libs). An apu which isn't usable because
>> it doesn't resolve apr is worthless.
>
> I proposed the same patch as was applied long ago for trunk earliert today for 2.2. That
> patch does not change apu-1-config behaviour.
>
> Not sure whether I agree that apu should provide info about apr, since one could argue
> that that's what apr-1-config is for. So I cross post dev@apr and this part of the
> discussion could proceed there.
>
>> That's how all .pc and other include/lib resolvers are supposed to behave.
>>
>> The same must be true for the linker.
You might want to review man pkg-config --cflags. Note --includes is in the
plural.
If the user can't use the apu_dbd API by simply plugging in apr-util, then
we did something wrong.
Re: [Vote] httpd 2.2.22 release
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/30/2012 12:27 PM, Rainer Jung wrote:
> On 30.01.2012 19:10, William A. Rowe Jr. wrote:
>> On 1/30/2012 4:02 AM, Rainer Jung wrote:
>>>
>>> We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect
>>> which version we have. That works for most gcc versions, but recent gcc chokes, because
>>> apu_version.h includes apr_version.h, which can not be found due to our setting of
>>> CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check
>>> fails.
>>>
>>> Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version
>>> check fixes this.
>>
>> That is a bug in apu-1-config; which must include the apr-1 path in
>> its reported --includes (and --libs). An apu which isn't usable because
>> it doesn't resolve apr is worthless.
>
> I proposed the same patch as was applied long ago for trunk earliert today for 2.2. That
> patch does not change apu-1-config behaviour.
>
> Not sure whether I agree that apu should provide info about apr, since one could argue
> that that's what apr-1-config is for. So I cross post dev@apr and this part of the
> discussion could proceed there.
>
>> That's how all .pc and other include/lib resolvers are supposed to behave.
>>
>> The same must be true for the linker.
You might want to review man pkg-config --cflags. Note --includes is in the
plural.
If the user can't use the apu_dbd API by simply plugging in apr-util, then
we did something wrong.
Re: [Vote] httpd 2.2.22 release
Posted by Rainer Jung <ra...@kippdata.de>.
On 30.01.2012 19:10, William A. Rowe Jr. wrote:
> On 1/30/2012 4:02 AM, Rainer Jung wrote:
>>
>> We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect
>> which version we have. That works for most gcc versions, but recent gcc chokes, because
>> apu_version.h includes apr_version.h, which can not be found due to our setting of
>> CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails.
>>
>> Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version
>> check fixes this.
>
> That is a bug in apu-1-config; which must include the apr-1 path in
> its reported --includes (and --libs). An apu which isn't usable because
> it doesn't resolve apr is worthless.
I proposed the same patch as was applied long ago for trunk earliert
today for 2.2. That patch does not change apu-1-config behaviour.
Not sure whether I agree that apu should provide info about apr, since
one could argue that that's what apr-1-config is for. So I cross post
dev@apr and this part of the discussion could proceed there.
> That's how all .pc and other include/lib resolvers are supposed to behave.
>
> The same must be true for the linker.
Regards,
Rainer
Re: [Vote] httpd 2.2.22 release
Posted by Rainer Jung <ra...@kippdata.de>.
On 30.01.2012 19:10, William A. Rowe Jr. wrote:
> On 1/30/2012 4:02 AM, Rainer Jung wrote:
>>
>> We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to detect
>> which version we have. That works for most gcc versions, but recent gcc chokes, because
>> apu_version.h includes apr_version.h, which can not be found due to our setting of
>> CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version check fails.
>>
>> Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before the version
>> check fixes this.
>
> That is a bug in apu-1-config; which must include the apr-1 path in
> its reported --includes (and --libs). An apu which isn't usable because
> it doesn't resolve apr is worthless.
I proposed the same patch as was applied long ago for trunk earliert
today for 2.2. That patch does not change apu-1-config behaviour.
Not sure whether I agree that apu should provide info about apr, since
one could argue that that's what apr-1-config is for. So I cross post
dev@apr and this part of the discussion could proceed there.
> That's how all .pc and other include/lib resolvers are supposed to behave.
>
> The same must be true for the linker.
Regards,
Rainer