On 06/29/2012 07:32 PM, Richard Purdie wrote:
On Fri, 2012-06-29 at 17:36 +0800, Robert Yang wrote:The native perl is installed to: ${STAGING_BINDIR_NATIVE}/perl-native/perl But this isn't in the PATH, so we can use the native perl by the command "perl" or "#!/usr/bin/env perl". I wonder why we install the perl to ${STAGING_BINDIR_NATIVE}/perl-native, but not to ${STAGING_BINDIR_NATIVE}. It would be good if we can add ${STAGING_BINDIR_NATIVE}/perl-native to the path or install the native perl to ${STAGING_BINDIR_NATIVE}, I will send a patch for it if you are ok with it.No, this is very deliberately not in PATH by default. Please see the mailing list archives and the original patches that implemented this to understand why. Such a patch will not be accepted. What problem are you trying to fix?
Thanks, the problem is that when "#!/very/long/path/to/perl" in a perl script, there would be an error "Bad interpreter: No such file or directory", when the length of "#!/very/long/path/" is longer than 170 (or smaller), the script which has this problem is the dpkg-scanpackages (and other dpkg-* scripts, but they don't run when generate the rootfs of deb backend)) we can use "#!/usr/bin/env perl" to fix this problem if the native perl is in the PATH, and we can't use the host's perl since the host perl's @INC doesn't contain the native perl's module which is needed by dpkg-scanpackages. I think that I can use "/path/to/native-perl/perl dpkg-scanpackages" to fix this problem since we can't add the native perl to the PATH. // Robert
Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
