I have one machine that runs Windows 10 with Bash on Ubuntu on Windows. It uses some kind of FUSE filesystem that has no proper hard link support.
Because of this, a typical perl compilation fails. If I want to compile, I need to do:
echo "dont_use_nlink='define'" >> Policy.sh
./Configure -des
make
make install
What I'd ideally want is to be able to use either perlbrew or plenv to manage my perls and pass the dont_use_nlink parameter to any perl I build. Is there any way to do this?
Fortunately, it looks like the underlying issue in Win10 WSL is fixed, and will be (hopefully) released soon.
As MichielB pointed out, -A or -D seem like they should accomplish this, but it appears from some of my testing that perl's Configure doesn't honor -A or -D arguments when -de is also passed (see "usage" in perl's metaconfig for the significance of those args). Despite clearly seeing properly formed -A and -D flags in the args list of the generated config.sh, the dont_use_nlink never gets added.
As it happens, perlbrew passes those as the defaults unless you use the special PERLBREW_CONFIGURE_FLAGS environment variable.
However, there is a workaround. You can use PERLBREW_CONFIGURE_FLAGS to use -f to pass our own configuration file. We can use the mostly-correct config.sh generated by a failed "perlbrew install" run, then tweak it and pass it in.
Steps:
Run a perlbrew install that will fail, eg:
perlbrew install perl-5.24.0
Copy the generated config.sh file somewhere for modification and reuse:
cp /home/USERNAME/perl5/perlbrew/build/perl-5.24.0/config.sh ~/config_dont_use_nlink.sh
Edit the file to and insert dont_use_nlink='define'. If you're being tidy and filing it alphabetically, it'll go between dlsrc and doubleinfbytes:
dlsrc='dl_dlopen.xs'
dont_use_nlink='define'
doubleinfbytes='0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x7f'
Run perlbrew install, but set an environment variable that will cause "-f" to be passed through to the new perl's Configure script:
PERLBREW_CONFIGURE_FLAGS="-de -f /home/USERNAME/config_dont_use_nlink.sh" perlbrew install perl-5.24.0
That compiles for me on a mostly-clean WSL on Win10 build 14393, and has nearly all tests pass (with the remainder looking like stuff with WSL bugs already filed).
I haven't looked at Windows 10 or the new bash shell for Windows, so I don't know how compatible that new Windows bash environment is with perlbrew or plenv.
An alternative approach would be to leverage versions of portable Strawberry Perl. A while back, David Farrell wrote berrybrew to mimic perlbrew on Windows using portable Strawberry Perl rather than compiling Perl from source code. He wrote a blog post about it and put his stuff out on GitHub (berrybrew). Later, Steve Bertrand wanted to add more functionality and eventually ended up forking the project. You can read more about it on his blog post and his forked project is out on GitHub (see here).
Unless you're needing/wanting to build Perl versions from source code, using berrybrew may provide you with the functionality that you're looking for.
Related
I have found it necessary to expand upon a CPAN module. (Unicode::CharName goes up to Unicode 4.1; I need some characters from Unicode 5.0 & 5.1).
I've made the changes needed and have my own CharName.pm module.
I now would like to use it with my various Perls. I currently use:
Strawberry Perl for Windows
git for Windows MINGW64; My .bashrc sets
$PATH to Strawberry perl and $PERL5LIB=/c/Strawberry/perl/vendor/lib:/c/Strawberry/perl/site/lib
WSL Ubuntu
Where should I put my version of Unicode::CharName, so that it over-rides the ones installed by CPAN?
I don't want to have to change any scripts that currently
use Unicode::CharName;
Using cpanm you could download the module, patch it, and install it as normal:
$ cpanm --look Unicode::CharName
# new shell opens
$ patch lib/Unicode/CharName.pm custom.patch # or whatever process
$ perl Makefile.PL
$ make install
$ exit
You can also install it to a local::lib to avoid overwriting it globally, by adding the -l local/ option to the cpanm command. Then you can add the absolute path of this local::lib to your PERL5LIB or via -I or use lib. If you specified /path/to/local for the -l option, it would be /path/to/local/lib/perl5.
Manually copying files rather than going through the normal installation process is likely to lead to problems. Many distributions depend on the installation process to build the modules correctly. Also, you will need to install the module separately for each Perl you want to use it for; installed Perl modules are not generally cross-compatible between Perl versions or architectures. (A strictly simple pure-Perl module can be an exception to these rules, but the only module I feel comfortable abusing this way is App::cpanminus, because it was designed to do this.)
What is the easiest way to install Perl under $prefix/lib/perl5/perl5.X instead of $prefix/lib/perl5/perl5.X.Y? In current scheme all binaries linking against libperl.dylib stop working when I replace the old version of Perl with a new one (because a theoretically ABI-compatible library gets moved to a different location).
The Configure file contains
case "$installstyle" in
*lib/perl5*) set dflt privlib lib/$package/$version ;;
and $version is set to 5.X.Y, but I'm not sure how to safely fix that path without breaking anything.
As mob has already suggested, don't try to change where perl is installing, instead just setup a symlink to point to the version that you want to use.
ln -s $prefix/lib/perl5/perl5.X $prefix/lib/perl5/perl5.X.Y
However, I believe you probably could use an introduction to perlbrew. perlbrew is a tool to manage multiple perl installations in your $HOME directory. This would enable you to install a new version without risking your other development environments, and switch between versions of perl seamlessly.
mv $prefix/lib/perl5/perl5.X.Y $prefix/lib/perl5/perl5.X
ln -s $prefix/lib/perl5/perl5.X $prefix/lib/perl5/perl5.X.Y
?
Searching the web, I have found almost no evidence that perlbrew works on cygwin. The specifics of my current issue are:
With the latest install of cygwin (which includes perl 5.14.2), I'm trying to install perl-5.14.2 using the latest perlbrew, installed from the web (not CPAN). I get a hang just after ../dist/threads-shared/t/shared_attr.t...ok is printed to build.log. This is on WinXP Pro 2002 SP3. Previous tries at using perlbrew on other builds of cygwin (which include perl 5.10.1) have also failed, but in other places.
I have posted a comment on Reini Urban's blog on blogs.perl.org and an issue/bug on github for App-perlbrew, but with no responses yet.
Is there any hope that I can get perl to build on cygwin? If not, what can I do to work around it and still use perlbrew (to unify my environments so that my cygwin environment uses perlbrew, just like my linux environment does)?
perlbrew works and perl can be built on Cygwin, with the minor annoyance that some of the unit tests hang (as you have discovered). Keep one eye on the build process output and kill the tests (usually thread related) that don't do anything for a couple of minutes using ps and kill. perlbrew should (knock on wood) run make install even if a handful of tests did not pass.
I never got perlbrew run under cygwin. But as a workaround perhaps try plenv. When I last tried it, it worked out of the box under cygwin.
A 2018 update - perlbrew works fine for me on Cygwin. However, perlbrew-installed perls will not have the patches that a system Perl has. I have a sample repo at https://github.com/cxw42/perlbrew-on-cygwin showing how I built the latest Cygwin system perl and installed it as a perlbrew perl.
In short, building Perl with prefix, site prefix, and vendor prefix set to ~/perl5/perlbrew/perls/perl-<version> will generate a Perl tree. You can drop that Perl tree into ~/perl5/perlbrew/perls/, and perlbrew will pick it up as an available Perl.
I'm trying to track down a segmentation fault that I've been able to isolate to just a few lines of code on different versions of Perl. I use perlbrew to manage my various versions for development and testing, but it doesn't build perl with debugging symbols, so using gdb to analyse the core dump file is pretty useless.
So what's the best way to have perlbrew build with debugging symbols enabled. And if possible I'd like to be able to have it be a separate perl that I could switch to instead of overriding the standard one for the same version.
perlbrew install -v 5.14.2 --as=5.14.2d -DEBUGGING=-g
(--as puts it under a different name, so you can keep your existing builds.)
There's also the following which includes the above and stuff you surely don't need:
perlbrew install -v 5.14.2 --as=5.14.2d -DEBUGGING=both
See INSTALL in the root dir of the Perl distro.
I am wanting to create an install script in the fashion of npm's (curl http://example.com/install.sh | sh) but it leaves me asking the question: can I just write the script in perl? As far as I know, perl is installed by default on at least ubuntu, RHEL & OS X - so I'm wondering in the year 2011, can I not write shell and still be generic enough for everyone? Is there a third and better option?
This would be targeting a user's development box, not staging or production.
What I want to do specifically is use this install script to bootstrap a development environment easily without the overhead of creating and maintaining packages. The script would have 4 steps:
check and make sure git is installed
use git to clone a repo to cwd
pull down and save a perl control script to /usr/bin, make it executable
add some environment variables (related post: linux cross-distro environment variable modification via script?)
That's it. My thinking is this is simple and generic enough to use a bootstrap script rather than a package. And my target audience is a user's unix or linux local development system.
The best option is to simply use the existing, well-oiled and -used (development) toolchain for the language the target app is written in. Not doing so frivolously discards the network effects gained from the ecologies that have grown around them.
C: GNU autotools
Haskell: Cabal
Perl: EU::MM, M::B, M::I
etc. etc.
Installing from the Web should be reserved for conveniently bootstrapping a user's system into the development environment.
Do tell more details about your software to get less general advice.
Edit: response to your addendum.
I dissuade you from a Web installer. This isn't bootstrapping an installation tool, this is plain installation of software and it should be done with with e.g. a Module::Build subclass.
I think perl is ubiquitous enough for you to write your installer in it. Shell is a lot more awkward anyway.
You might want to consider actually packaging your application as a deb or rpm or even using makeself rather than providing a raw script.
Here's a list of the various distributions of perl:
https://www.socialtext.net/perl5/distributions
Even if perl doesn't ship on every little obscure distro it's just an apt-get (or whatever) away. You might run into problems due to the various versions of perl installed however.
Use something like:
perl -E "$( wget -q -O - http://host/intall.pl )"
Also you can use
`cmd`
instead of
$(cmd)
but anyway, double-quote your choice.