On Oct 24, 2011, at 4:35 PM, ext Jeremiah Foster wrote: > On Mon, Oct 24, 2011 at 2:02 PM, Lauri T. Aarnio > <lauri.t.aar...@nokia.com> wrote: >> On Oct 21, 2011, at 9:33 PM, ext Carsten Munk wrote: >>> 2011/10/21 Lauri T. Aarnio <lauri.t.aar...@nokia.com>: >>>> 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.
No, no. You missed the point completely. First, I know pretty well what perl is. I'm actually old enough to remember those times when the first version of perl was posted to the net... and I also think I know something about how it is used in the real world. You don't have to try to teach me the basics. But the question is not at all how *I* would configure something for our environment, or how *I* would use it in my packages. And it is not only related to how a language gets built, it is even more related to how it is used. By someone else than me or you. Instead, this discussion is about setting up a cross-building environment where also somebody else's tools and scripts could be safely and efficiently executed. Without modifications to the perl configuration, and more importantly without modifications to the tools implemented in perl. Something like perlbrew is totally unsuitable for such environments. And my previous post was not about difficulties in installing many perls in parallel. It is of course possible, but I'm saying that it should not be done at all that way; if a perl program was written to be executed with /usr/bin/perl in the build environment, then it must do so. It must not revert to something like /scratchbox/tools/bin/perl (a practice is SB1, not used in SB2). I have spent a lot of time analyzing problems related to these things, and implemented some environment-level solutions, too. Unfortunately perl (and how it is used) presents one of the most tricky problem domains in this sense. The main reason is simple: Perl and perl programs make up probably the easiest way to leak information about the build environment to the compiled packages. For example, we have seen packages that "got infected by SB1" and afterwards work fine in SB1, but don't work in the real target environment. Claiming that all this would be "spreading FUD" is just bullsh*t. Uncertainty isn't involved - this is a been-there-done-that thing. BR, Lauri PS. Note that I'm not claiming that SB2's strategy of overloading /usr/bin/perl would solve everything. But it is a nice start, fixes many but not all perl-related oddities. _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines