[OE-core] [PATCH 37/58] gnu-config-native: add dependency on perl-native

[Cui, Dexuan]

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, at 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