Patchwork [37/58] gnu-config-native: add dependency on perl-native

login
register
mail settings
Submitter Saul Wold
Date April 16, 2011, 6:54 a.m.
Message ID <eee3fb921c3e9c6439df2540a552719c9327ebd4.1302936483.git.sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/2409/
State New, archived
Headers show

Comments

Saul Wold - April 16, 2011, 6:54 a.m.
From: Dexuan Cui <dexuan.cui@intel.com>

Fixes [YOCTO #968]

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
---
 .../gnu-config/config-guess-uclibc.patch           |    2 ++
 .../gnu-config/gnu-config_20080123.bb              |    6 ++++--
 2 files changed, 6 insertions(+), 2 deletions(-)
Richard Purdie - April 18, 2011, 4:53 a.m.
On Fri, 2011-04-15 at 23:54 -0700, Saul Wold wrote:
> From: Dexuan Cui <dexuan.cui@intel.com>
> 
> Fixes [YOCTO #968]
> 
> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
> ---
>  .../gnu-config/config-guess-uclibc.patch           |    2 ++
>  .../gnu-config/gnu-config_20080123.bb              |    6 ++++--
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch b/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
> index f820cef..f862c83 100644
> --- a/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
> +++ b/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
> @@ -1,3 +1,5 @@
> +Upstream-Status: Pending
> +
>  Patch courtesy gentoo-portage/sys-devel/gnuconfig/files/automake-1.8.5-config-guess-uclibc.patch.
>  
>  updated to 20050516 by Marcin 'Hrw' Juszkiewicz (by hand)
> diff --git a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
> index e0a8155..897984d 100644
> --- a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
> +++ b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
> @@ -3,12 +3,14 @@ DESCRIPTION = "Tool that installs the GNU config.guess / config.sub into a direc
>  SECTION = "devel"
>  LICENSE = "GPLv1+"
>  LIC_FILES_CHKSUM = "file://config.guess;endline=39;md5=a089987af4a25cb0419d1c2fd6d495e3"
> -DEPENDS = ""
> +
> +DEPENDS_virtclass-native = "perl-native"
> +
>  INHIBIT_DEFAULT_DEPS = "1"
>  


I haven't taken this. Having looked at the shear number of horrible
perl-native issues, I'd like to take the same approach we took with the
toolchain staging and place perl into its own bin directory we add to
PATH when needed. I commented on at least one of the bugs in this
respect.

Cheers,

Richard
Dexuan Cui - April 18, 2011, 5:43 a.m.
Richard Purdie wrote:
> On Fri, 2011-04-15 at 23:54 -0700, Saul Wold wrote:
>> From: Dexuan Cui <dexuan.cui@intel.com>
>> 
>> Fixes [YOCTO #968]
>> 
>> diff --git a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
>> b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb 
>> index e0a8155..897984d 100644
>> --- a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
>> +++ b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
>> @@ -3,12 +3,14 @@ DESCRIPTION = "Tool that installs the GNU
>>  config.guess / config.sub into a direc  SECTION = "devel" LICENSE =
>>  "GPLv1+" LIC_FILES_CHKSUM =
>> "file://config.guess;endline=39;md5=a089987af4a25cb0419d1c2fd6d495e3"
>> -DEPENDS = "" + +DEPENDS_virtclass-native = "perl-native"
>> +
>>  INHIBIT_DEFAULT_DEPS = "1"
>> 
> 
> 
> I haven't taken this. Having looked at the shear number of horrible
> perl-native issues, I'd like to take the same approach we took with
> the toolchain staging and place perl into its own bin directory we
> add to PATH when needed. 
Hi RP,
If a recipe does need perl-native but we fail to realize that, the host's perl (e.g. /usr/bin/perl) will be used -- this will further hinder us from realizing the recipe needs perl-native.

As to bug #968, the build failure happens because perl-native's do_populate_sysroot has begun but hasn't finished. If perl-native hasn't started to populate_sysroot, running gnu-configize won't fail since host's perl will be used.

so I've 3 questions:
1) in poky how to exclude host's perl from PATH? need to write a python function to filter out various possible host perl paths? e.g., ~/bin/perl, /usr/local/bin/perl, /usr/bin/perl, /bin/perl,... too many paths...

2) how to identify the recipes that need perl-native? I think we have to identify them manually one by one? This is time comsuming?

3) Even if we solve the above 2 issues, we still need to add perl-native into the recipes' (that need perl-native) DEPENDS, correct?

I'm not sure my above understanding is ok. Please correct me if I'm wrong.

Thanks,
-- Dexuan
Richard Purdie - April 18, 2011, 6:54 a.m.
On Mon, 2011-04-18 at 13:43 +0800, Cui, Dexuan wrote:
> Richard Purdie wrote:
> > On Fri, 2011-04-15 at 23:54 -0700, Saul Wold wrote:
> >> @@ -3,12 +3,14 @@ DESCRIPTION = "Tool that installs the GNU
> >>  config.guess / config.sub into a direc  SECTION = "devel" LICENSE =
> >>  "GPLv1+" LIC_FILES_CHKSUM =
> >> "file://config.guess;endline=39;md5=a089987af4a25cb0419d1c2fd6d495e3"
> >> -DEPENDS = "" + +DEPENDS_virtclass-native = "perl-native"
> >> +
> >>  INHIBIT_DEFAULT_DEPS = "1"
> > 
> > I haven't taken this. Having looked at the shear number of horrible
> > perl-native issues, I'd like to take the same approach we took with
> > the toolchain staging and place perl into its own bin directory we
> > add to PATH when needed. 
>
> If a recipe does need perl-native but we fail to realize that, the
> host's perl (e.g. /usr/bin/perl) will be used -- this will further
> hinder us from realizing the recipe needs perl-native.
> 
> As to bug #968, the build failure happens because perl-native's
> do_populate_sysroot has begun but hasn't finished. If perl-native
> hasn't started to populate_sysroot, running gnu-configize won't fail
> since host's perl will be used.
> 
> so I've 3 questions:
> 1) in poky how to exclude host's perl from PATH? need to write a
> python function to filter out various possible host perl paths? e.g.,
> ~/bin/perl, /usr/local/bin/perl, /usr/bin/perl, /bin/perl,... too many
> paths...
> 
> 2) how to identify the recipes that need perl-native? I think we have
> to identify them manually one by one? This is time comsuming?
> 
> 3) Even if we solve the above 2 issues, we still need to add
> perl-native into the recipes' (that need perl-native) DEPENDS,
> correct?
> 
> I'm not sure my above understanding is ok. Please correct me if I'm
> wrong.

What I'd like to do is have perl install into a bindir which isn't part
of our PATH by default. For anything which has DEPENDS = "perl-native",
we add this directory to PATH. Anything that doesn't have the DEPENDS
doesn't see it. We can probably make this a perlnative.bbclass or
something which just contains

PATH_prepend = "${STAGING_BINDIR_NATIVE}/perl-native:"
DEPENDS += "perl-native"

This should ensure that anything that really needs perl-native finds it
but we don't have *everything* depending on it unnecessarily.

Cheers,

Richard
Dexuan Cui - April 18, 2011, 2:18 p.m.
Richard Purdie wrote:
> On Mon, 2011-04-18 at 13:43 +0800, Cui, Dexuan wrote:
>> Richard Purdie wrote:
>>> On Fri, 2011-04-15 at 23:54 -0700, Saul Wold wrote:
>>>> @@ -3,12 +3,14 @@ DESCRIPTION = "Tool that installs the GNU
>>>>  config.guess / config.sub into a direc  SECTION = "devel" LICENSE
>>>> =  "GPLv1+" LIC_FILES_CHKSUM =
>>>> "file://config.guess;endline=39;md5=a089987af4a25cb0419d1c2fd6d495e3"
>>>>  -DEPENDS = "" + +DEPENDS_virtclass-native = "perl-native" +
>>>> INHIBIT_DEFAULT_DEPS = "1" 
>>> 
>>> I haven't taken this. Having looked at the shear number of horrible
>>> perl-native issues, I'd like to take the same approach we took with
>>> the toolchain staging and place perl into its own bin directory we
>>> add to PATH when needed.
>> 
>> If a recipe does need perl-native but we fail to realize that, the
>> host's perl (e.g. /usr/bin/perl) will be used -- this will further
>> hinder us from realizing the recipe needs perl-native.
>> 
>> As to bug #968, the build failure happens because perl-native's
>> do_populate_sysroot has begun but hasn't finished. If perl-native
>> hasn't started to populate_sysroot, running gnu-configize won't fail
>> since host's perl will be used.
>> 
>> so I've 3 questions:
>> 1) in poky how to exclude host's perl from PATH? need to write a
>> python function to filter out various possible host perl paths? e.g.,
>> ~/bin/perl, /usr/local/bin/perl, /usr/bin/perl, /bin/perl,... too
>> many paths... 
>> 
>> 2) how to identify the recipes that need perl-native? I think we have
>> to identify them manually one by one? This is time comsuming?
>> 
>> 3) Even if we solve the above 2 issues, we still need to add
>> perl-native into the recipes' (that need perl-native) DEPENDS,
>> correct? 
>> 
>> I'm not sure my above understanding is ok. Please correct me if I'm
>> wrong.
> 
> What I'd like to do is have perl install into a bindir which isn't
> part of our PATH by default. For anything which has DEPENDS =
> "perl-native", we add this directory to PATH. Anything that doesn't
> have the DEPENDS doesn't see it. We can probably make this a
> perlnative.bbclass or something which just contains
> 
> PATH_prepend = "${STAGING_BINDIR_NATIVE}/perl-native:"
> DEPENDS += "perl-native"
> 
> This should ensure that anything that really needs perl-native finds
> it but we don't have *everything* depending on it unnecessarily.

Hi Richard,
Thanks very much for the detailed explanation!
Now I understand and will make changes accordingly.

Thanks,
-- Dexuan
Dexuan Cui - May 5, 2011, 2:18 p.m.
Richard Purdie wrote:
> On Mon, 2011-04-18 at 13:43 +0800, Cui, Dexuan wrote:
>> Richard Purdie wrote:
>>> On Fri, 2011-04-15 at 23:54 -0700, Saul Wold wrote:
>>>> @@ -3,12 +3,14 @@ DESCRIPTION = "Tool that installs the GNU
>>>>  config.guess / config.sub into a direc  SECTION = "devel" LICENSE
>>>> =  "GPLv1+" LIC_FILES_CHKSUM =
>>>> "file://config.guess;endline=39;md5=a089987af4a25cb0419d1c2fd6d495e3"
>>>>  -DEPENDS = "" + +DEPENDS_virtclass-native = "perl-native" +
>>>> INHIBIT_DEFAULT_DEPS = "1" 
>>> 
>>> I haven't taken this. Having looked at the shear number of horrible
>>> perl-native issues, I'd like to take the same approach we took with
>>> the toolchain staging and place perl into its own bin directory we
>>> add to PATH when needed.
>> 
>> If a recipe does need perl-native but we fail to realize that, the
>> host's perl (e.g. /usr/bin/perl) will be used -- this will further
>> hinder us from realizing the recipe needs perl-native.
>> 
>> As to bug #968, the build failure happens because perl-native's
>> do_populate_sysroot has begun but hasn't finished. If perl-native
>> hasn't started to populate_sysroot, running gnu-configize won't fail
>> since host's perl will be used.
>> 
>> so I've 3 questions:
>> 1) in poky how to exclude host's perl from PATH? need to write a
>> python function to filter out various possible host perl paths? e.g.,
>> ~/bin/perl, /usr/local/bin/perl, /usr/bin/perl, /bin/perl,... too
>> many paths... 
>> 
>> 2) how to identify the recipes that need perl-native? I think we have
>> to identify them manually one by one? This is time comsuming?
>> 
>> 3) Even if we solve the above 2 issues, we still need to add
>> perl-native into the recipes' (that need perl-native) DEPENDS,
>> correct? 
>> 
>> I'm not sure my above understanding is ok. Please correct me if I'm
>> wrong.
> 
> What I'd like to do is have perl install into a bindir which isn't
> part of our PATH by default. For anything which has DEPENDS =
> "perl-native", we add this directory to PATH. Anything that doesn't
> have the DEPENDS doesn't see it. We can probably make this a
> perlnative.bbclass or something which just contains
> 
> PATH_prepend = "${STAGING_BINDIR_NATIVE}/perl-native:"
> DEPENDS += "perl-native"
> 
> This should ensure that anything that really needs perl-native finds
> it but we don't have *everything* depending on it unnecessarily.
Hi RP,
(Sorry for my delay for the task as I was working on other bugs...)
Recently I have been looking into it and I've made some commits (the
top 5 small commits) in
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native 
BTW: the work is not done completely as some recipes don't build
with the changes. Please have a look anyway to see if I'm in the correct direction.

However, I've got some difficulties and hope to get your help:
1)  As you said, after we install perl-native into its own directory, any recipe not depending on perl-native doesn't see ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
However, if we keep the current code, what's the bad consequence if the recipe not depending on perl-native does see perl of perl-native? looks no?

2) In poky, I see many places hardcodedly use the system perl(i.e., /usr/bin/perl) explicitly or implicitly(e.g,  meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in contains /usr/bin/perl; another example,  in perl-5.12.3's source code, Cross/generate_config_sh also contains #!/usr/bin/perl). Should we fix all of them?
   And what's the relationship between the system perl and perl-native? Since perl-native is not less functional than the system perl, will we eliminate the system perl as a prerequisite to bitbake in future?

3) In gnu-config_20080123.bb's do_install, I don't understand this lines: here the "!=" should be "="?
    if [ "${BUILD_ARCH}" != "${TARGET_ARCH}" ]; then
        sed -i -e 's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize
    fi
e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked; when building gnu-config, the sed will be invoked, but bindir is just /usr/bin, so the replacement operation actually does nothing.

And for gnu-config-native, I think we need do a 
sed -i -e 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g' ${D}${bindir}/gnu-configize
Correct?

4) My last commit of the top 5 commits is a chaos... I'm trying to replace every "DEPENDS on perl-native" with "inherit perlnative".
I'm now stuck in fixing the build issues for libxml-parser-perl and libxml-parser-perl-native.
I don't know how to fix get_perl_version and perl_get_libdirs in cpan-base.bbclass -- for libxml-parser-perl-native, I have to manage to add a "/perl-native" into STAGING_LIBDIR and libdir, but for libxml-parser-perl, I can't change STAGING_LIBDIR and libdir. Can you please help me out?

Thanks!

-- Dexuan
Richard Purdie - May 5, 2011, 10:34 p.m.
On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
> (Sorry for my delay for the task as I was working on other bugs...)
> Recently I have been looking into it and I've made some commits (the
> top 5 small commits) in
> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native 
> BTW: the work is not done completely as some recipes don't build
> with the changes. Please have a look anyway to see if I'm in the correct direction.
> 
> However, I've got some difficulties and hope to get your help:
> 1)  As you said, after we install perl-native into its own directory,
> any recipe not depending on perl-native doesn't see
> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
> However, if we keep the current code, what's the bad consequence if
> the recipe not depending on perl-native does see perl of perl-native?
> looks no?

We have an assumption that perl is already on the system we're building
on. Perl is a relatively stable language with defined compatibility and
interoperability. Most recipes are therefore fine using perl from the
build system directly and don't need perl-native. I think we defined a
special name for the build system perl (perl-native-runtime?). Better
names are welcome but we should ensure we use the right dependency in
the right places.

The time to use perl-native instead of perl-native-runtime is where any
perl module is being built, perl itself is being built or anything that
has an explicit dependency on the perl version present.

> 2) In poky, I see many places hardcodedly use the system
> perl(i.e., /usr/bin/perl) explicitly or implicitly(e.g,
> meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in
> contains /usr/bin/perl; another example,  in perl-5.12.3's source
> code, Cross/generate_config_sh also contains #!/usr/bin/perl). Should
> we fix all of them?

Most of these should be generated locations and I think this is fine
since most of these are "perl-native-runtime" uses and its fine to use
the build system perl.

>    And what's the relationship between the system perl and
> perl-native? Since perl-native is not less functional than the system
> perl, will we eliminate the system perl as a prerequisite to bitbake
> in future?

No, I think you have this backwards. The intent is to have
"perl-native-runtime" denoting a requirement on the build system perl
and "perl-native" being a perl that exactly the same as the target perl
for cross purposes.

> 3) In gnu-config_20080123.bb's do_install, I don't understand this lines: here the "!=" should be "="?
>     if [ "${BUILD_ARCH}" != "${TARGET_ARCH}" ]; then
>         sed -i -e 's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize
>     fi

This means it only applies for non-native packages. (native has
BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
with things like the nativesdk packages where bindir != "/usr/bin".

> e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
> host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
> when building gnu-config, the sed will be invoked, but bindir is
> just /usr/bin, so the replacement operation actually does nothing.

You can define a system where exec_prefix is "" and bindir is hence
"/bin" when it wouldn't do nothing.

> And for gnu-config-native, I think we need do a 
> sed -i -e 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g' ${D}${bindir}/gnu-configize
> Correct?

No, the whole point is to stop it seeing perl-native. Only perl itself
and modules should be using perl-native.

> 4) My last commit of the top 5 commits is a chaos... I'm trying to
> replace every "DEPENDS on perl-native" with "inherit perlnative".
> I'm now stuck in fixing the build issues for libxml-parser-perl and libxml-parser-perl-native.
> I don't know how to fix get_perl_version and perl_get_libdirs in
> cpan-base.bbclass -- for libxml-parser-perl-native, I have to manage
> to add a "/perl-native" into STAGING_LIBDIR and libdir, but for
> libxml-parser-perl, I can't change STAGING_LIBDIR and libdir. Can you
> please help me out?

I'd suggest splitting this into two steps:

a) Check through all perl-native references and correct the ones that 
   should be perl-native-runtime.
b) Replace all remaining perl-native references with the class 
   dependency.

In step a), gnu-config would have a dependency on perl-native-runtime so
wouldn't use the perlnative class.

Just for reference, using perl-native-runtime means that someone can
remove it from ASSUME_PROVIDED and provide a version of it themselves if
they so wish (using perl-native or otherwise).

I suspect you'll still have the libxml-parser-perl problem but lets take
this one step at a time! :)

Cheers,

Richard
Dexuan Cui - May 6, 2011, 8:52 a.m.
Richard Purdie wrote:
> On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
>> Recently I have been looking into it and I've made some commits
>> ......
>> 1)  As you said, after we install perl-native into its own directory,
>> any recipe not depending on perl-native doesn't see
>> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
>> However, if we keep the current code, what's the bad consequence if
>> the recipe not depending on perl-native does see perl of perl-native?
>> looks no?
> 
> We have an assumption that perl is already on the system we're
> building on. Perl is a relatively stable language with defined
> compatibility and interoperability. Most recipes are therefore fine
> using perl from the build system directly and don't need perl-native.
> I think we defined a special name for the build system perl
> (perl-native-runtime?). Better names are welcome but we should ensure
> we use the right dependency in the right places.
> 
> The time to use perl-native instead of perl-native-runtime is where
> any perl module is being built, perl itself is being built or
> anything that has an explicit dependency on the perl version present.
Thanks for all the clarification!

>> 3) In gnu-config_20080123.bb's do_install, I don't understand this
>>     lines: here the "!=" should be "="? if [ "${BUILD_ARCH}" !=
>>         "${TARGET_ARCH}" ]; then sed -i -e
>>     's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
> 
> This means it only applies for non-native packages. (native has
> BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
> with things like the nativesdk packages where bindir != "/usr/bin".
Thanks for the explanation!
My understanding about "non-native package" is target recipe (in this case bindir=/usr/bin)
and -nativesdk recipe.
gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
contain nativesdk), so looks the sed replacement is useless at present?


>> e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
>> host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
>> when building gnu-config, the sed will be invoked, but bindir is
>> just /usr/bin, so the replacement operation actually does nothing.
> 
> You can define a system where exec_prefix is "" and bindir is hence
> "/bin" when it wouldn't do nothing.
> 
>> And for gnu-config-native, I think we need do a
>> sed -i -e
>> 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g'
>> ${D}${bindir}/gnu-configize Correct? 
> 
> No, the whole point is to stop it seeing perl-native. Only perl itself
> and modules should be using perl-native.
So gnu-config-native should use perl-native-runtime(i.e., the system perl) and
shouldn't depend on perl-native.
Howeve, there is a sed replacement in gnu-config-native's do_install:
-e 's,@autom4te_perllibdir@,${datadir}/autoconf,g
and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is intened
to be run with "#! /usr/bin/env perl" -- this incurs some race conditions:
1) if perl-natvie does populate_sysroot later than
${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is used
but perl-native's modules are used due to the "unshift @INC, $datadir" in gnu-configize.in.
This is just http://bugzilla.pokylinux.org/show_bug.cgi?id=941
2)  if perl-natvie does populate_sysroot earlier than the gnu-configize
is invokded, we don't meet bug 941.

The above is the current situation. If we install perl-native into its own
sysroot, in the gnu-configize, the system perl is always found and used,
and we always meet with bug 941.

How can we fix bug 941 then?

BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S "$0" "$@";; esac'
    if 0;
I'm new to the synax of perl, but I believe the string after the "eval" is
not executed due to "if 0".
Can we remove the 2 lines?

> 
>> 4) My last commit of the top 5 commits is a chaos... I'm trying to
>> replace every "DEPENDS on perl-native" with "inherit perlnative".
>> I'm now stuck in fixing the build issues for libxml-parser-perl and
>> libxml-parser-perl-native. 
>> I don't know how to fix get_perl_version and perl_get_libdirs in
>> cpan-base.bbclass -- for libxml-parser-perl-native, I have to manage
>> to add a "/perl-native" into STAGING_LIBDIR and libdir, but for
>> libxml-parser-perl, I can't change STAGING_LIBDIR and libdir. Can you
>> please help me out?
> 
> I'd suggest splitting this into two steps:
> 
> a) Check through all perl-native references and correct the ones that
>    should be perl-native-runtime.
> b) Replace all remaining perl-native references with the class
>    dependency.
Ok, I'm checking all the references.

> In step a), gnu-config would have a dependency on perl-native-runtime
> so wouldn't use the perlnative class.
Please see my above reply.

> Just for reference, using perl-native-runtime means that someone can
> remove it from ASSUME_PROVIDED and provide a version of it themselves
> if they so wish (using perl-native or otherwise).
> 
> I suspect you'll still have the libxml-parser-perl problem but lets
> take this one step at a time! :)
I'll continue to try to fix this. :-)

Richard, thanks a lot for your help!

-- Dexuan
Richard Purdie - May 6, 2011, 11:31 a.m.
On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
> Richard Purdie wrote:
> >> 3) In gnu-config_20080123.bb's do_install, I don't understand this
> >>     lines: here the "!=" should be "="? if [ "${BUILD_ARCH}" !=
> >>         "${TARGET_ARCH}" ]; then sed -i -e
> >>     's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
> > 
> > This means it only applies for non-native packages. (native has
> > BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
> > with things like the nativesdk packages where bindir != "/usr/bin".
> Thanks for the explanation!
> My understanding about "non-native package" is target recipe (in this case bindir=/usr/bin)
> and -nativesdk recipe.
> gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
> contain nativesdk), so looks the sed replacement is useless at present?

Not useless but not heavily used directly in Poky at this time.
DISTRO=minimal in OE for example sets exec_prefix="" so bindir
becomes /bin.

> >> e.g. when building gnu-config-native for MACHINE qemux86 on a 32-bit
> >> host,  BUILD_ARCH=TARGET_ARCH=i686-linux and the sed isn't invoked;
> >> when building gnu-config, the sed will be invoked, but bindir is
> >> just /usr/bin, so the replacement operation actually does nothing.
> > 
> > You can define a system where exec_prefix is "" and bindir is hence
> > "/bin" when it wouldn't do nothing.

As I mentioned here :)

> >> And for gnu-config-native, I think we need do a
> >> sed -i -e
> >> 's,/usr/bin/perl,${STAGING_BINDIR_NATIVE}/perl-native/perl,g'
> >> ${D}${bindir}/gnu-configize Correct? 
> > 
> > No, the whole point is to stop it seeing perl-native. Only perl itself
> > and modules should be using perl-native.
> So gnu-config-native should use perl-native-runtime(i.e., the system perl) and
> shouldn't depend on perl-native.

Correct.

> Howeve, there is a sed replacement in gnu-config-native's do_install:
> -e 's,@autom4te_perllibdir@,${datadir}/autoconf,g

Don't confuse the data files that autoconf installs and references with
a program that is mixing the perl-native binary and libraries with the
host system ones. I think the above change is harmless as its just
linking in some perl files.

> and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is intened
> to be run with "#! /usr/bin/env perl" -- this incurs some race conditions:

This is more problematic though as it does this but also references
perl's full path more directly further in the file. This is the real
problem as its mixing and matching two different perl versions.

> 1) if perl-natvie does populate_sysroot later than
> ${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is used
> but perl-native's modules are used due to the "unshift @INC, $datadir" in gnu-configize.in.
> This is just http://bugzilla.pokylinux.org/show_bug.cgi?id=941
> 2)  if perl-natvie does populate_sysroot earlier than the gnu-configize
> is invokded, we don't meet bug 941.
> 
> The above is the current situation. If we install perl-native into its own
> sysroot, in the gnu-configize, the system perl is always found and used,
> and we always meet with bug 941.

It doesn't matter which perl we use but we do need to use the same perl
consistently.

> How can we fix bug 941 then?
> 
> BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
> eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec /usr/bin/perl -S "$0" "$@";; esac'
>     if 0;
> I'm new to the synax of perl, but I believe the string after the "eval" is
> not executed due to "if 0".
> Can we remove the 2 lines?

I ended up getting some other opinions on this code as it makes no sense
to me either. The best guess I've heard is its allowing the script to
work in shell and perl. I then looked at other autoconf scripts and they
use this same construct so its obviously copied from there. I agree the
style is pointless and we could remove it but it is at least consistent
with the rest of autoconf.

I went digging and was surprised to see many hardcoded paths to perl in
the autoconf scripts. It turns out path_prog_fixes.patch isn't being
applied to autoconf-native, only the target version. When we do apply
it, it turns out the patch is buggy in the native case and I had to
change @bindir@/env to /usr/bin/env to make it work since we don't have
a "env" in the STAGING_BINDIR_NATIVE.

My point is that we need to be consistent about which perl version we
use in these scripts. Either we use one from the environment using env
or we hardcode to /usr/bin/perl. Since the perl-native binary won't be
in the path for any of these, autodetecting and letting it hardcode is
probably fine. It has the advantage that if there are any binary modules
ever involved, they'll match the version of perl they were built for
regardless of whether perl-native is a dependency or not. If someone
adds a perl-native dependency to autoconf-native, it will also still
select the "correct" perl.

Whilst doing this we need to keep bug #968 in mind and ensure that if
perl-native is used, all of perl-native is in the sysroot. That bug is
where the perl binary was installed, the library was not and an error
occurred. If it is in its own directory which is only added to the PATH
for users with the correct dependency, we avoid this.

As for bug #941, the bottom line is that however autoconf-native selects
its perl version, the strings encoded in gnu-config should really match
those in the other autoconf-native scripts.

Cheers,

Richard
Koen Kooi - May 6, 2011, 12:02 p.m.
Op 6 mei 2011, om 13:31 heeft Richard Purdie het volgende geschreven:

> On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
>> Richard Purdie wrote:
>>>> 3) In gnu-config_20080123.bb's do_install, I don't understand this
>>>>    lines: here the "!=" should be "="? if [ "${BUILD_ARCH}" !=
>>>>        "${TARGET_ARCH}" ]; then sed -i -e
>>>>    's,/usr/bin/env,${bindir}/env,g' ${D}${bindir}/gnu-configize fi
>>> 
>>> This means it only applies for non-native packages. (native has
>>> BUILD_ARCH=TARGET_ARCH). The path to env is ${bindir} and this assists
>>> with things like the nativesdk packages where bindir != "/usr/bin".
>> Thanks for the explanation!
>> My understanding about "non-native package" is target recipe (in this case bindir=/usr/bin)
>> and -nativesdk recipe.
>> gnu-config_20080123.bb doesn't have -nativesdk version(BBCLASSEXTEND doesn't
>> contain nativesdk), so looks the sed replacement is useless at present?
> 
> Not useless but not heavily used directly in Poky at this time.
> DISTRO=minimal in OE for example sets exec_prefix="" so bindir
> becomes /bin.

Nitpick: that's DISTRO=micro
Tom Rini - May 6, 2011, 2:27 p.m.
On 05/05/2011 03:34 PM, Richard Purdie wrote:
> On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
>> (Sorry for my delay for the task as I was working on other bugs...)
>> Recently I have been looking into it and I've made some commits (the
>> top 5 small commits) in
>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native 
>> BTW: the work is not done completely as some recipes don't build
>> with the changes. Please have a look anyway to see if I'm in the correct direction.
>>
>> However, I've got some difficulties and hope to get your help:
>> 1)  As you said, after we install perl-native into its own directory,
>> any recipe not depending on perl-native doesn't see
>> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
>> However, if we keep the current code, what's the bad consequence if
>> the recipe not depending on perl-native does see perl of perl-native?
>> looks no?
> 
> We have an assumption that perl is already on the system we're building
> on. Perl is a relatively stable language with defined compatibility and
> interoperability. Most recipes are therefore fine using perl from the
> build system directly and don't need perl-native. I think we defined a
> special name for the build system perl (perl-native-runtime?). Better
> names are welcome but we should ensure we use the right dependency in
> the right places.
> 
> The time to use perl-native instead of perl-native-runtime is where any
> perl module is being built, perl itself is being built or anything that
> has an explicit dependency on the perl version present.

The problem that follows up is that once we have built any sort of
perl-native we then have to go and be really really really careful that
nothing that's not (a) target perl (b) some perl module we built and
need to run uses it.  Otherwise we run into the problems I think that've
been hit here.  Problems like this are why for OE I just made
perl-native be the perl we rely on for everything.

I know we talked about this before and you had a strong desire to try
and do something else but I think this shows maybe we need to try going
down the perl-native everywhere path first and then see if we can't do
something different.
Dexuan Cui - May 10, 2011, 2:02 p.m.
Richard Purdie wrote:
> On Fri, 2011-05-06 at 16:52 +0800, Cui, Dexuan wrote:
>> Howeve, there is a sed replacement in gnu-config-native's do_install:
>> -e 's,@autom4te_perllibdir@,${datadir}/autoconf,g
> 
> Don't confuse the data files that autoconf installs and references
> with a program that is mixing the perl-native binary and libraries
> with the host system ones. I think the above change is harmless as
> its just linking in some perl files.
Sorry, but I might not make me clear here(?) 
I meant:  due to the sed replacing and the 
"unshift @INC, $datadir"(@INC is a path list
from which a perl module is being searched for) in
${STAGING_BINDIR_NATIVE}/gnu-configize, /usr/bin/perl will try to use
perl modues in ${STAGING_DATADIR_NATIVE}/perl/ if the gnu-configize
is executed by /usr/bin/perl.
That's just bug 941, I think.
If we keep the sed replacing, I think we have to make gnu-config-native
depend on perl-native so we're sure gnu-config-native's do_configure will
find perl-native rather than /usr/bin/perl, but as you said, gnu-config-native
should not depend on perl-native. That's what confused me.

>> and meta/recipes-devtools/gnu-config/gnu-config/gnu-configize.in is
>> intened 
>> to be run with "#! /usr/bin/env perl" -- this incurs some race
>> conditions: 
> 
> This is more problematic though as it does this but also references
> perl's full path more directly further in the file. This is the real
> problem as its mixing and matching two different perl versions.
> 
>> 1) if perl-natvie does populate_sysroot later than
>> ${STAGING_BINDIR_NATIVE}/gnu-configize is invoked, /usr/bin/perl is
>> used 
>> but perl-native's modules are used due to the "unshift @INC,
>> $datadir" in gnu-configize.in. This is just
>> http://bugzilla.pokylinux.org/show_bug.cgi?id=941 2)  if perl-natvie
>> does populate_sysroot earlier than the gnu-configize 
>> is invokded, we don't meet bug 941.
>> 
>> The above is the current situation. If we install perl-native into
>> its own 
>> sysroot, in the gnu-configize, the system perl is always found and
>> used, 
>> and we always meet with bug 941.
> 
> It doesn't matter which perl we use but we do need to use the same
> perl consistently.
> 
>> How can we fix bug 941 then?
>> 
>> BTW: the 2 lines at the beginning of gnu-configize.in is suspicious:
>> eval 'case $# in 0) exec /usr/bin/perl -S "$0";; *) exec
>> /usr/bin/perl -S "$0" "$@";; esac'     if 0; I'm new to the synax of
>> perl, but I believe the string after the "eval" is 
>> not executed due to "if 0".
>> Can we remove the 2 lines?
> 
> I ended up getting some other opinions on this code as it makes no
> sense to me either. The best guess I've heard is its allowing the
> script to work in shell and perl. I then looked at other autoconf
> scripts and they use this same construct so its obviously copied from
> there. I agree the style is pointless and we could remove it but it
> is at least consistent with the rest of autoconf.
> 
> I went digging and was surprised to see many hardcoded paths to perl
> in the autoconf scripts. It turns out path_prog_fixes.patch isn't
> being applied to autoconf-native, only the target version. When we do
> apply it, it turns out the patch is buggy in the native case and I
> had to change @bindir@/env to /usr/bin/env to make it work since we
> don't have a "env" in the STAGING_BINDIR_NATIVE.
> 
> My point is that we need to be consistent about which perl version we
> use in these scripts. Either we use one from the environment using env
Yes, I agree.

> or we hardcode to /usr/bin/perl. Since the perl-native binary won't be
> in the path for any of these, autodetecting and letting it hardcode is
> probably fine. It has the advantage that if there are any binary
> modules ever involved, they'll match the version of perl they were
> built for regardless of whether perl-native is a dependency or not.
> If someone adds a perl-native dependency to autoconf-native, it will
> also still select the "correct" perl.
> 
> Whilst doing this we need to keep bug #968 in mind and ensure that if
> perl-native is used, all of perl-native is in the sysroot. That bug is
> where the perl binary was installed, the library was not and an error
> occurred. If it is in its own directory which is only added to the
> PATH for users with the correct dependency, we avoid this.
> 
> As for bug #941, the bottom line is that however autoconf-native
> selects its perl version, the strings encoded in gnu-config should
> really match those in the other autoconf-native scripts.
I saw a commit that was once suspended was pushed into poky
master yesterday:
http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
Actually it does fix(or at least workaround) bug #941 and bug #968.

Looks there are much work to do if we install perl-native to its own sysroot.
At present we can use the above commit as a workaround.

Thanks,
-- Dexuan
Dexuan Cui - May 10, 2011, 2:09 p.m.
Tom Rini wrote:
> On 05/05/2011 03:34 PM, Richard Purdie wrote:
>> On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
>>> Recently I have been looking into it and I've made some commits (the
>>> top 5 small commits) in
>>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native
>>> BTW: the work is not done completely as some recipes don't build
>>> with the changes. Please have a look anyway to see if I'm in the
>>> correct direction. 
>>> 
>>> However, I've got some difficulties and hope to get your help:
>>> 1)  As you said, after we install perl-native into its own
>>> directory, 
>>> any recipe not depending on perl-native doesn't see
>>> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
>>> However, if we keep the current code, what's the bad consequence if
>>> the recipe not depending on perl-native does see perl of
>>> perl-native? 
>>> looks no?
>> 
>> We have an assumption that perl is already on the system we're
>> building on. Perl is a relatively stable language with defined
>> compatibility and interoperability. Most recipes are therefore fine
>> using perl from the build system directly and don't need
>> perl-native. I think we defined a special name for the build system
>> perl (perl-native-runtime?). Better names are welcome but we should
>> ensure we use the right dependency in the right places. 
>> 
>> The time to use perl-native instead of perl-native-runtime is where
>> any perl module is being built, perl itself is being built or
>> anything that has an explicit dependency on the perl version present.
> 
> The problem that follows up is that once we have built any sort of
> perl-native we then have to go and be really really really careful
> that nothing that's not (a) target perl (b) some perl module we built
> and need to run uses it.  Otherwise we run into the problems I think
> that've been hit here.  Problems like this are why for OE I just made
> perl-native be the perl we rely on for everything.
> 
> I know we talked about this before and you had a strong desire to try
> and do something else but I think this shows maybe we need to try
> going down the perl-native everywhere path first and then see if we
> can't do something different.
Hi Tom, do you mean we should try to use perl-native first and try the
best to avoid using /usr/bin/perl?

Thanks,
-- Dexuan
Tom Rini - May 10, 2011, 2:10 p.m.
On 05/10/2011 07:09 AM, Cui, Dexuan wrote:
> Tom Rini wrote:
>> On 05/05/2011 03:34 PM, Richard Purdie wrote:
>>> On Thu, 2011-05-05 at 22:18 +0800, Cui, Dexuan wrote:
>>>> Recently I have been looking into it and I've made some commits (the
>>>> top 5 small commits) in
>>>> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=dcui/master_perl-native
>>>> BTW: the work is not done completely as some recipes don't build
>>>> with the changes. Please have a look anyway to see if I'm in the
>>>> correct direction. 
>>>>
>>>> However, I've got some difficulties and hope to get your help:
>>>> 1)  As you said, after we install perl-native into its own
>>>> directory, 
>>>> any recipe not depending on perl-native doesn't see
>>>> ${STAGING_BINDIR_NATIVE}/perl-native/perl unnecessarily.
>>>> However, if we keep the current code, what's the bad consequence if
>>>> the recipe not depending on perl-native does see perl of
>>>> perl-native? 
>>>> looks no?
>>>
>>> We have an assumption that perl is already on the system we're
>>> building on. Perl is a relatively stable language with defined
>>> compatibility and interoperability. Most recipes are therefore fine
>>> using perl from the build system directly and don't need
>>> perl-native. I think we defined a special name for the build system
>>> perl (perl-native-runtime?). Better names are welcome but we should
>>> ensure we use the right dependency in the right places. 
>>>
>>> The time to use perl-native instead of perl-native-runtime is where
>>> any perl module is being built, perl itself is being built or
>>> anything that has an explicit dependency on the perl version present.
>>
>> The problem that follows up is that once we have built any sort of
>> perl-native we then have to go and be really really really careful
>> that nothing that's not (a) target perl (b) some perl module we built
>> and need to run uses it.  Otherwise we run into the problems I think
>> that've been hit here.  Problems like this are why for OE I just made
>> perl-native be the perl we rely on for everything.
>>
>> I know we talked about this before and you had a strong desire to try
>> and do something else but I think this shows maybe we need to try
>> going down the perl-native everywhere path first and then see if we
>> can't do something different.
> Hi Tom, do you mean we should try to use perl-native first and try the
> best to avoid using /usr/bin/perl?

Yes.  Roughly, make automake-native/autoconf-native depend on
perl-native and perform a few changes to libtool-native and
gnu-config-native to make sure it uses /usr/bin/env perl.
Richard Purdie - May 10, 2011, 2:10 p.m.
On Tue, 2011-05-10 at 22:02 +0800, Cui, Dexuan wrote:
> > or we hardcode to /usr/bin/perl. Since the perl-native binary won't be
> > in the path for any of these, autodetecting and letting it hardcode is
> > probably fine. It has the advantage that if there are any binary
> > modules ever involved, they'll match the version of perl they were
> > built for regardless of whether perl-native is a dependency or not.
> > If someone adds a perl-native dependency to autoconf-native, it will
> > also still select the "correct" perl.
> > 
> > Whilst doing this we need to keep bug #968 in mind and ensure that if
> > perl-native is used, all of perl-native is in the sysroot. That bug is
> > where the perl binary was installed, the library was not and an error
> > occurred. If it is in its own directory which is only added to the
> > PATH for users with the correct dependency, we avoid this.
> > 
> > As for bug #941, the bottom line is that however autoconf-native
> > selects its perl version, the strings encoded in gnu-config should
> > really match those in the other autoconf-native scripts.
> I saw a commit that was once suspended was pushed into poky
> master yesterday:
> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
> Actually it does fix(or at least workaround) bug #941 and bug #968.
> 
> Looks there are much work to do if we install perl-native to its own sysroot.
> At present we can use the above commit as a workaround.

Its merged as a workaround but I still think we need to clean this up
properly and we need to continue working on it.

Cheers,

Richard
Dexuan Cui - May 10, 2011, 2:20 p.m.
Richard Purdie wrote:
> On Tue, 2011-05-10 at 22:02 +0800, Cui, Dexuan wrote:
>>> or we hardcode to /usr/bin/perl. Since the perl-native binary won't
>>> be in the path for any of these, autodetecting and letting it
>>> hardcode is probably fine. It has the advantage that if there are
>>> any binary modules ever involved, they'll match the version of perl
>>> they were built for regardless of whether perl-native is a
>>> dependency or not. If someone adds a perl-native dependency to
>>> autoconf-native, it will also still select the "correct" perl.
>>> 
>>> Whilst doing this we need to keep bug #968 in mind and ensure that
>>> if perl-native is used, all of perl-native is in the sysroot. That
>>> bug is where the perl binary was installed, the library was not and
>>> an error occurred. If it is in its own directory which is only
>>> added to the PATH for users with the correct dependency, we avoid
>>> this. 
>>> 
>>> As for bug #941, the bottom line is that however autoconf-native
>>> selects its perl version, the strings encoded in gnu-config should
>>> really match those in the other autoconf-native scripts.
>> I saw a commit that was once suspended was pushed into poky
>> master yesterday:
>> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
>> Actually it does fix(or at least workaround) bug #941 and bug #968.
>> 
>> Looks there are much work to do if we install perl-native to its own
>> sysroot. At present we can use the above commit as a workaround.
> 
> Its merged as a workaround but I still think we need to clean this up
> properly and we need to continue working on it.
I actually meant the priority could be lowered since we have a workaround. :-)
Surely, I'll continue to investigate it.

Thanks,
-- Dexuan
Saul Wold - May 11, 2011, 12:50 a.m.
On 05/10/2011 07:20 AM, Cui, Dexuan wrote:
> Richard Purdie wrote:
>> On Tue, 2011-05-10 at 22:02 +0800, Cui, Dexuan wrote:
>>>> or we hardcode to /usr/bin/perl. Since the perl-native binary won't
>>>> be in the path for any of these, autodetecting and letting it
>>>> hardcode is probably fine. It has the advantage that if there are
>>>> any binary modules ever involved, they'll match the version of perl
>>>> they were built for regardless of whether perl-native is a
>>>> dependency or not. If someone adds a perl-native dependency to
>>>> autoconf-native, it will also still select the "correct" perl.
>>>>
>>>> Whilst doing this we need to keep bug #968 in mind and ensure that
>>>> if perl-native is used, all of perl-native is in the sysroot. That
>>>> bug is where the perl binary was installed, the library was not and
>>>> an error occurred. If it is in its own directory which is only
>>>> added to the PATH for users with the correct dependency, we avoid
>>>> this.
>>>>
>>>> As for bug #941, the bottom line is that however autoconf-native
>>>> selects its perl version, the strings encoded in gnu-config should
>>>> really match those in the other autoconf-native scripts.
>>> I saw a commit that was once suspended was pushed into poky
>>> master yesterday:
>>> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
>>> Actually it does fix(or at least workaround) bug #941 and bug #968.
>>>
>>> Looks there are much work to do if we install perl-native to its own
>>> sysroot. At present we can use the above commit as a workaround.
>>
>> Its merged as a workaround but I still think we need to clean this up
>> properly and we need to continue working on it.
> I actually meant the priority could be lowered since we have a workaround. :-)
> Surely, I'll continue to investigate it.
>
Just to be clear, just because we have a work around does not mean we 
can lower the priority, this is still a valid bug that needs a proper 
patch in a timely manner.

941 is still a major bug and requires a fix before the milestone 1 
release stabilization period (May 20), which is 10 days from now.

Sau!


> Thanks,
> -- Dexuan
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Dexuan Cui - May 11, 2011, 1 a.m.
Saul Wold wrote:
> On 05/10/2011 07:20 AM, Cui, Dexuan wrote:
>> Richard Purdie wrote:
>>> On Tue, 2011-05-10 at 22:02 +0800, Cui, Dexuan wrote:
>>>>> or we hardcode to /usr/bin/perl. Since the perl-native binary
>>>>> won't be in the path for any of these, autodetecting and letting
>>>>> it hardcode is probably fine. It has the advantage that if there
>>>>> are any binary modules ever involved, they'll match the version
>>>>> of perl they were built for regardless of whether perl-native is a
>>>>> dependency or not. If someone adds a perl-native dependency to
>>>>> autoconf-native, it will also still select the "correct" perl.
>>>>> 
>>>>> Whilst doing this we need to keep bug #968 in mind and ensure that
>>>>> if perl-native is used, all of perl-native is in the sysroot. That
>>>>> bug is where the perl binary was installed, the library was not
>>>>> and an error occurred. If it is in its own directory which is only
>>>>> added to the PATH for users with the correct dependency, we avoid
>>>>> this. 
>>>>> 
>>>>> As for bug #941, the bottom line is that however autoconf-native
>>>>> selects its perl version, the strings encoded in gnu-config should
>>>>> really match those in the other autoconf-native scripts.
>>>> I saw a commit that was once suspended was pushed into poky
>>>> master yesterday:
>>>> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=605141a93443df042634b2219a8628a9004be023
>>>> Actually it does fix(or at least workaround) bug #941 and bug #968.
>>>> 
>>>> Looks there are much work to do if we install perl-native to its
>>>> own sysroot. At present we can use the above commit as a
>>>> workaround. 
>>> 
>>> Its merged as a workaround but I still think we need to clean this
>>> up properly and we need to continue working on it.
>> I actually meant the priority could be lowered since we have a
>> workaround. :-) Surely, I'll continue to investigate it.
>> 
> Just to be clear, just because we have a work around does not mean we
> can lower the priority, this is still a valid bug that needs a proper
> patch in a timely manner.
> 
> 941 is still a major bug and requires a fix before the milestone 1
> release stabilization period (May 20), which is 10 days from now.
OK, so I'll put more effort on this to get a complete fix.

Thanks,
-- Dexuan

Patch

diff --git a/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch b/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
index f820cef..f862c83 100644
--- a/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
+++ b/meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch
@@ -1,3 +1,5 @@ 
+Upstream-Status: Pending
+
 Patch courtesy gentoo-portage/sys-devel/gnuconfig/files/automake-1.8.5-config-guess-uclibc.patch.
 
 updated to 20050516 by Marcin 'Hrw' Juszkiewicz (by hand)
diff --git a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
index e0a8155..897984d 100644
--- a/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
+++ b/meta/recipes-devtools/gnu-config/gnu-config_20080123.bb
@@ -3,12 +3,14 @@  DESCRIPTION = "Tool that installs the GNU config.guess / config.sub into a direc
 SECTION = "devel"
 LICENSE = "GPLv1+"
 LIC_FILES_CHKSUM = "file://config.guess;endline=39;md5=a089987af4a25cb0419d1c2fd6d495e3"
-DEPENDS = ""
+
+DEPENDS_virtclass-native = "perl-native"
+
 INHIBIT_DEFAULT_DEPS = "1"
 
 FIXEDSRCDATE = "${@bb.data.getVar('FILE', d, 1).split('_')[-1].split('.')[0]}"
 PV = "0.1+cvs${FIXEDSRCDATE}"
-PR = "r2"
+PR = "r3"
 
 SRC_URI = "cvs://anonymous@cvs.sv.gnu.org/cvsroot/config;module=config;method=pserver;date=${FIXEDSRCDATE} \
 	   file://config-guess-uclibc.patch \