[OE-core] [PATCH 2/4] ICU: add pkgconfig support
ChenQi
Qi.Chen at windriver.com
Wed Dec 12 08:58:59 UTC 2012
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 at linux.intel.com>
>>> wrote:
>>>> On 12/10/2012 08:48 AM, Saul Wold wrote:
>>>>>
>>>>> On 12/04/2012 12:46 AM, Qi.Chen at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121212/685544aa/attachment-0002.html>
More information about the Openembedded-core
mailing list