Re: [PATCH 2/4] ICU: add pkgconfig support

[ChenQi <Qi.Chen@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 3833 bytes --]

On 12/12/2012 04:48 PM, ChenQi wrote:
> On 12/11/2012 09:59 AM, Saul Wold wrote:
>> On 12/10/2012 05:07 PM, Andreas Müller wrote:
>>> On Mon, Dec 10, 2012 at 10:44 PM, Saul Wold <sgw@linux.intel.com> 
>>> wrote:
>>>> On 12/10/2012 08:48 AM, Saul Wold wrote:
>>>>>
>>>>> On 12/04/2012 12:46 AM, Qi.Chen@windriver.com wrote:
>>>>>>
>> <SNIP>
>>>>>>               "
>>>>>>    SRC_URI = "${BASE_SRC_URI} \
>>>>>>               file://noldlibpath.patch \
>>>>>> @@ -28,6 +29,12 @@ inherit autotools pkgconfig binconfig
>>>>>>    do_configure() {
>>>>>>        libtoolize --force
>>>>>>        gnu-configize --force
>>>>>> +    if [ "${PN}" != "icu-native" ]; then
>>>>>> +        OLD=`pwd`
>>>>>> +        cd ${S}
>>>>>> +        autoconf
>>>>>> +        cd ${OLD}
>>>>>> +    fi
>>>>
>>>>
>>>> I had some time this morning to investigate this more deeply.  What 
>>>> I found
>>>> was that the ICU tarball was being delivered with a "configure" and 
>>>> that the
>>>> do_configure was avoiding the "autoconf" conversion of configure.in ->
>>>> configure.  I am not sure if this is historical or if this is truly 
>>>> needed.
>>>>
>>>> So by doing the autoconf above you changed the "configure" script, 
>>>> this in
>>>> turn caused some configuration changes to occur in the platform.h 
>>>> file.  Why
>>>> these changed (particularly the U_HAVE_NAMESPACE define) then 
>>>> caused the ICU
>>>> libraries to be built with different namespace.
>>>>
>>>> So a couple of key questions that need to be resolved:
>>>> 1) Will updating to 4.6 solve this issue, if not then we need to 
>>>> dive into 2
>>>> + 3 Below:
>>>>
>>>> 2) Why does icu tarball have a generated configure?
>>>>
>>>> 3) Why does the autoconf generated configure fail to configure things
>>>> correctly?
>>>>
>>>> Sau!
>>>>
>>> Also got this error but reported it to the wrong mailing list - sorry.
>>> I also looked around for this. The patch added pkg-config to icu. Just
>>> a guess: webkit-gtk fails due to a mixture of renamed symbols
>>> (EventListener_3_6 - see sysroot/usr/include/unicode/urename.h) and
>>> unrenamed symbols. Before the icu-patch this did not happen because
>>> (icu's) urename.h was not included and no symbols were renamed or
>>> renamed differently. My problem: The error gives me information about
>>> renamed symbol but I did not yet find the time to search for
>>> unrenamed. As I said: Just a guess
>>>
>> I am not sure that's it, the renaming is actually in the NAMESPACE, 
>> the older (no pkg-config) sets HAVE_NAMESPACE in the platform.h file 
>> and then the symbols have icu_2_6 in them, that's the real issue, 
>> which is caused by running autoconf and getting a bad/wrong 
>> "configure" script vs the one suplied in the tarball.
>>
>> Sau!
>>
>>> Andreas
>>>
>>>
>>
> Hi Saul,
>
> The errors are:
> configure.in:219: error: possibly undefined macro: 
> AC_CHECK_STRICT_COMPILE
>       If this token and others are legitimate, please use 
> m4_pattern_allow.
>       See the Autoconf documentation.
> configure.in:222: error: possibly undefined macro: AC_CHECK_64BIT_LIBS
> configure.in:492: error: possibly undefined macro: AC_SEARCH_LIBS_FIRST
>

Ah.... I see the problem. Our autoconf version is 2.69 while this 
configure.ac file needs 2.68.
> The recipe's in attachment.
>
> I first tried it on my own computer without yocto, everything's OK. 
> The autoconf-generated configure is the same with the shipped one. So 
> I figured maybe we don't need to override the do_configure and 
> do_compile method here.
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


[-- Attachment #2: Type: text/html, Size: 7509 bytes --]