[oe] libxml2-native build against host zlib.h

[Jader H. Silva]

Tom Rini escreveu:
> On Tue, Apr 07, 2009 at 04:01:58PM -0300, Jader H. Silva wrote:
>   
>> Tom Rini escreveu:
>>     
>>> On Tue, Apr 07, 2009 at 02:54:35PM -0300, Jader H. Silva wrote:
>>>   
>>>       
>>>> Koen Kooi escreveu:
>>>>     
>>>>         
>>>>> On 23-03-09 20:10, Jader H. Silva wrote:
>>>>>       
>>>>>           
>>>>>>     It seems libxml2-native is built using host zlib.h.
>>>>>>     My host have a symbol redefinition in zlib.h (gzopen ->    
>>>>>> gzopen64), but
>>>>>>     that symbol does not exists in OE compiled library.
>>>>>>     Setting --with-zlib=${STAGING_INCIR}/zlib.h in libxml2-native.inc
>>>>>>     solved it. There's a patch attached.
>>>>>>         
>>>>>>             
>>>>> The patch seems to solve the problem, could you resend a version 
>>>>> that  bumps the PR as well? Once this in .dev we should apply it to 
>>>>>  stable/2008 as well.
>>>>>
>>>>> regards,
>>>>>
>>>>> Koen
>>>>>       
>>>>>           
>>>> Patch with compilation fix and PR update is attached.
>>>>     
>>>>         
>>> As Khem pointed out previously, this is not correct, NACK.  From the
>>> configure script --help:
>>>   --with-zlib[=DIR]       use libz in DIR
>>> So this should be adding '--with-zlib=${STAGING_INCIR}'
>>>
>>>   
>>>       
>> --with-zlib=${STAGING_INCDIR} don't fix it.
>>     
>
> That's odd.  Reading libxml2-native-2.7.2-r2/libxml2-2.7.2/configure I
> don't see how that value being a file and not a dir could work.  In
> fact, moving my system zlib.h out of the way and reading config.log I
> see things like:
> configure:12246: checking zlib.h usability
> configure:12263: gcc -c
> -isystem/home/trini/work/OE-upstream/tmp.4.3.3/staging/x86_64-linux/usr/include
> -O2
> -isystem/home/trini/work/OE-upstream/tmp.4.3.3/staging/x86_64-linux/usr/include
> conftest.c >&5
> configure:12269: $? = 0
> configure:12283: result: yes
> configure:12287: checking zlib.h presence
> configure:12302: gcc -E
> -isystem/home/trini/work/OE-upstream/tmp.4.3.3/staging/x86_64-linux/usr/include
> conftest.c
> configure:12308: $? = 0
> configure:12322: result: yes
> configure:12350: checking for zlib.h
> configure:12358: result: yes
>   
It is indeed really puzzling. It was a simple test check when anything 
else didn't work.
> Can you tell us more about what host system you're using and possibly
> just as importantly what config.log looks like when you use your patch?
> I'm not saying you don't have a failure, I'm just saying it's puzzling
> that your patch works.
>   
I'm using ubuntu 8.04, zlib1g-dev package is installed.
I can compile it without problems in a machine where zlib1g-dev is not 
installed.

Attached there's the log.do_compile and config.log.nok originated from a 
failed compilation and config.log from a successful compilation after my 
patch was applied.
> Also, trying to figure out when zlib-native gets pulled in and I see
> it's coming from file-native, so perhaps we should, while we're in here
> anyhow, add zlib-native to the dep list for libxml2-native?
>
>   
I agree that is most likely to correctly solve this problem. I will try 
it and report back.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: text/x-log
Size: 117467 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090407/07a56434/attachment-0002.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config.log.nok
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090407/07a56434/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.do_compile.32719
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090407/07a56434/attachment-0005.ksh>