Re: [oe-commits] Frans Meulenbroeks : flex: added perl to dependencies

Re: [oe-commits] Frans Meulenbroeks : flex: added perl to dependencies

[Tom Rini]

On 11/21/2010 06:40 AM, git version control wrote:
> Module: openembedded.git
> Branch: org.openembedded.dev
> Commit: c3b5b68541320ed0104d8654a0793251ed0187b9
> URL:    http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=c3b5b68541320ed0104d8654a0793251ed0187b9
>
> Author: Frans Meulenbroeks<fransmeulenbroeks@gmail.com>
> Date:   Sun Nov 21 10:15:08 2010 +0100
>
> flex: added perl to dependencies
>
> Without it (rebuilding from packaged staging) I got:
>
> | /home/frans/oe/tmp_minimal/work/i686-linux/flex-native-2.5.35-r5.1/temp/run.do_configure.12240:
> /home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/bin/automake:
> /home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/bin/perl: bad interpreter: No such file or directory

This starts to open up the very large can of worms of stuff that uses 
host perl (autotools, etc) and then what happens once perl-native has 
been built and installed.  I've mentioned this before in
http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08445.html

-- 
Tom Rini
Mentor Graphics Corporation

Re: [oe-commits] Frans Meulenbroeks : flex: added perl to dependencies

[Frans Meulenbroeks]

2010/11/21 Tom Rini <tom_rini@mentor.com>:
> On 11/21/2010 06:40 AM, git version control wrote:
>>
>> Module: openembedded.git
>> Branch: org.openembedded.dev
>> Commit: c3b5b68541320ed0104d8654a0793251ed0187b9
>> URL:
>>  http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=c3b5b68541320ed0104d8654a0793251ed0187b9
>>
>> Author: Frans Meulenbroeks<fransmeulenbroeks@gmail.com>
>> Date:   Sun Nov 21 10:15:08 2010 +0100
>>
>> flex: added perl to dependencies
>>
>> Without it (rebuilding from packaged staging) I got:
>>
>> |
>> /home/frans/oe/tmp_minimal/work/i686-linux/flex-native-2.5.35-r5.1/temp/run.do_configure.12240:
>> /home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/bin/automake:
>> /home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/bin/perl: bad
>> interpreter: No such file or directory
>
> This starts to open up the very large can of worms of stuff that uses host
> perl (autotools, etc) and then what happens once perl-native has been built
> and installed.  I've mentioned this before in
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08445.html

After reading the archive and discussing this on irc.

I feel DEPENDS should be complete (minus perhaps a few things that are
always there, e.g. no depends on patch needed).

I understand the very long pathname problem, but I don't think it is
good to "solve" that by deferring building of perl-native (or
restoring it from packaged staging).
That solution does not work if someone rebuilds a package that suffers
from the long path problem.

Some alternate solutions (most of them coined in the thread mentioned before).
- always use perl from the host; not too desirable as the host version
may not be what you want.
- use perl from host for standard things (like configure etc), have a
package (e.g. perl-cross) for things that really need perl on the host
for the target (I can imagine libperl* recipes need this)
- use /usr/bin/env perl instead of the long path
- relax the line length of the command interpreter so longer paths are
ok. Guess that would mean having a bash-native or so.
- create (sym)links and use these. E.g. we could have $TMPDIR/links
where there is a link for perl to the long path. By adding
$TMPDIR/links to the front of the path executables in it wll be picked
up first.

Guess there are plenty other ways to skin this cat.
My personal preference is using /usr/bin/env perl. This seems the
cleanest solution.

Best regards, Frans