On Mon, Oct 24, 2011 at 2:02 PM, Lauri T. Aarnio <[email protected]> wrote: > On Oct 21, 2011, at 9:33 PM, ext Carsten Munk wrote: >> 2011/10/21 Lauri T. Aarnio <[email protected]>: >>> On Oct 21, 2011, at 4:05 PM, ext Carsten Munk wrote:
> >> OK, that is a fairly clever approach. I wonder if >> we could do something similar with the approach we currently use for >> cross compilation. > > Probably not, without risking something else. > > Perl is an extremely tricky tool, which makes already itself use of far too > many "clever" features that are available. > > One example is that built-in variable $^X is implemented by reading where > /proc/self/exe symlink points to. > And many scripts actually record that to something what they produce [this > was the original reason why SB2 got a special handler for the /proc FS!] > > This means that you should not install perl anywhere else than to > /usr/bin/perl. So something like a simple redirector at /usr/bin, which would > determine what version to use and then exec a perl from somewhere else, would > just create more problems that what it would solve. > > The same applies to the locations of the libraries, etc. => In theory it is > possible to change the default locations, but in practice it it just a stupid > thing to try. You're spreading FUD. Perl runs a lot of architectures and platforms because it is flexible. Because you can't configure it for your cross-compilation environment is not the fault of how the language gets built. If you have problems, look at tools like perlbrew for pointers on how to install many perls, or ask questions on perl-5-porters. Regards, Jeremiah _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
