Question: Versions of Perl newer than build.me
cookiemonsteruk opened this issue · 13 comments
Hi again.
Currently binary build fails when running build.me script.
This is on FreeBSD 11.3 which has only Perl from 5.28 onwards.
I think it is because the perl check only goes to 5.26:
From line # 453
Path to Perl 5.26
if [ -x "/usr/bin/perl5.26.0" ]; then
PERL_526=/usr/bin/perl5.26.0
fi
if [ $PERL_526 ]; then
PERL_BIN=$PERL_526
PERL_MINOR_VER=26
fi
Would it be a bad idea for me to add a new block for 5.28 so it passes the check and attempt to build for this version by adding:
Path to Perl 5.28
if [ -x "/usr/bin/perl5.28.0" ]; then
PERL_528=/usr/bin/perl5.28.0
fi
if [ $PERL_528 ]; then
PERL_BIN=$PERL_528
PERL_MINOR_VER=28
fi
Yes - it is a bad idea. The main reason is because on FreeBSD, the Perl binaries don't reside in /usr/bin. The second reason is that the actual test for Perl should be conducted down at L469. This revised logic allows all Perl (including 5.28) to be properly detected and used on FreeBSD.
How did the build fail? What was the message?
Hi fsbruva. I haven't attempted to build it myself, my jail is at perl 5.26. Someone trying now on a jail on a higher freebsd base system is failing. That is freebsd 12.1. The lowest perl on packages for it is 5.28.3.
His reported failure appears as this:
root@lms:/tmp/slimserver-vendor-public-7.9/CPAN # ./buildme.sh -t | tee /tmp/build.log
RUN_TESTS:0 CLEAN:1 USE_HINTS:1 RENAME_x86:1 target all
Looks like your compiler is cc
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
./buildme.sh: line 469: perl: command not found
Failed to find supported Perl version for ''
Was this the same system that you said was 11.3 in your first comment (they upgraded to 12.1)?
What does his system show for the commands which perl and perl -v?
Hi. Hisf irst attempt was on an 11.3 jail. They since blew that jail to see if 12.1 would be more successful by building a new jail on 12.1.
I'm going to reproduce myself. I've now built a jail for this. This jail is on 11.3:
root@builder:/ # uname -a
FreeBSD builder.local 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0 r353706M: Fri Oct 18 02:02:16 CEST 2019 root@dev.xigmanas.com:/usr/obj/xigmanas/usr/src/sys/XIGMANAS-amd64 amd64
No perl installed yet. A pkg search brings:
perl5-5.32.0 Practical Extraction and Report Language
perl5-devel-5.33.1.201 Practical Extraction and Report Language
perl5.28-5.28.3 Practical Extraction and Report Language
perl5.30-5.30.3 Practical Extraction and Report Language
I'll install perl 5.30 and try to build lms, see how it goes for me.
Edit:
I haven't tried to build as it makes sense what might be happening.
I've installed slimserver-vendor dependencies in the read me; for perl I installed perl5.30 without issues. After a rehash:
root@builder:/ # which perl
perl: Command not found.
root@builder:/ # perl -v
perl: Command not found.
which would probably explain the failure to find a supported perl version. It is found here:
root@builder:/ # /usr/local/bin/perl5.30.3 -version
This is perl 5, version 30, subversion 3 (v5.30.3) built for amd64-freebsd-thread-multi
Therefore it looks like I need to do a symlink to /usr/local/bin/perl5.30.3. Should I do it from /usr/bin ?
I can confirm it builds correctly after a pair of symlinks are created to the perl binary from pkg.
ln -s /usr/local/bin/perl5.30.3 /usr/bin/perl
ln -s /usr/local/bin/perl5.30.3 /usr/bin/perl5
Therefore the failure to build is because the test for perl is looking in the "wrong" path for freebsd.
The path is /usr/local/bin/ , the test is in /usr/bin/
Should I create a new issue for it, to alter the perl test for freebsd?
Thanks for your diagnostic efforts. However, unless @mherger disagrees, the behavior you have described is not an issue that necessitates modification of buildme.sh, because you are using a non-standard configuration. If it requires any change - it might be to the README within CPAN.
Usually, FreeBSD automatically installs a symlink from /usr/local/bin/perl5.x.y to /usr/local/bin/perl, but only if you install the default perl. If you install from ports, you can specify DEFAULT_VERSIONS+=perl5=5.x within /etc/make.conf to mimic the default install behavior for non-default perl.
However, you selected a non-default Perl version, and chose to install it in such a way (from pkg) that means NO perl script (with #!/usr/local/bin/perl or #!/usr/bin/env perl as a shebang) will run properly without the symlink you created. This means two things:
- This is an issue with your non-standard configuration, not something that requires modification of the script. If the script were to be altered to add a test for your non-standard /usr/local/bin/perl5.30.3, then the script will also need to be altered later to add additional tests for /usr/local/bin/perl5.30.4, .5, .6 and so on. And this same set of alterations would need to be done for all other non-standard FreeBSD Perls (5.26, 5.28, etc.).
- The script already contains a method to enable use of a perl that isn't known as "perl" or doesn't reside in $PATH. Use the '-p' flag when calling the script. For example, you could delete the symlinks you created, and run:
bash buildme.sh -p /usr/local/bin/perl5.30.3
If you want to test this - delete the symlinks, remove perl5.30 (pkg delete perl5.30) and install default perl (pkg install perl5). Pkg will install the default perl (5.32 right now), pkg will automatically add the necessary symlinks, the script will automatically detect perl and build all modules successfully.
In case it wasn't clear - the script uses whatever gets returned from which perl as the Perl binary. The reason your attempt failed is because you didn't have a binary named 'perl' anywhere in your $PATH. Since /usr/local/bin is already in your $PATH, then when the default version of Perl gets installed, pkg symlinks the generic 'perl' to the actual installed Perl binary. All the /usr/bin/ stuff is because /usr/bin is where Linux usually installs binaries. In contrast, FreeBSD uses /usr/bin for non-rescue binaries that are included as part of the base system, and then everything else (ports, pkg) is installed into /usr/local/bin.
Thank you very much for the detailed explanation. I didn't realise that installing a package not by (pkg install perl5) even it listed in the available perl versions on (pkg search perl) wasn't standard.
I've looked at the installer message from (pkg install perl5.30):
Message from perl5.30-5.30.3:
The /usr/bin/perl symlink has been removed starting with Perl 5.20.
For shebangs, you should either use:
#!/usr/local/bin/perl
or
#!/usr/bin/env perl
The first one will only work if you have a /usr/local/bin/perl,
the second will work as long as perl is in PATH.
Therefore unfortunately the symlink isn't created anymore. However I agree in your assesment and moving the burden to the build.me script feels too onerous. I think a note in the README within CPAN would take care of it.
That UPDATING note serves to alert users that the symlink created in FreeBSD for ALL Perl versions 5.8 - 5.18 at /usr/bin/perl (and pointed to /usr/local/bin/perl5.x.y) isn't used anymore. Therefore, users should be aware that: 1. They may need to alter the shebang of their existing Perl scripts and 2. Porting a Perl script written for Linux will require modifying the shebang.
Therefore unfortunately the symlink isn't created anymore.
You are confusing two different symlinks. The symlink that isn't created anymore is the one at /usr/bin/perl. That's what the UPDATING note says. Since /usr/bin/ and /usr/local/bin are both in $PATH, the move out of /usr/bin was mostly semantic. FreeBSD stopped affording special treatment to one port in particular, ending the legacy of backwards compatibility to a time when Perl came bundled with the FreeBSD base.
The first one will only work if you have a /usr/local/bin/perl
This is educating users that if they put a path to perl in their shebang, it will only work if there is a file called, "perl" at that location.
The FreeBSD ports/pkg maintainers tend to assume you know what you are doing. As such, they assumed you had a compelling reason for selecting a specific, non-default version of Perl (5.30), AND you didn't want pkg to take the steps to make it your system's default perl. As such, they assume you are capable of the necessary configuration changes to make the non-default perl functional for your purposes.
The documentation about the /usr/local/bin/perl symlink is in the perl5.30 port's Makefile, and gets displayed when you build from the ports tree:
##################################################
This is *NOT* the DEFAULT perl version
It will *NOT* install /usr/local/bin/perl
It will *ONLY* install /usr/local/bin/perl5.30.3
The default Perl version currently is 5.32.
If you want to use this version as the default,
stop the build now, add this line to your
/etc/make.conf, and then restart the build.
DEFAULT_VERSIONS+=perl5=5.30
##################################################
Understood.
For users simply trying to use LMS most of this is gets buried in installation of dependencies outputs. Hence although you are right, I come to think the note in the CPAN README would be very useful.
Hi, what is the etiquette on these? Should I convert it to an issue to track any action?
I must admit that I didn't follow all of what you discussed. So if there's something actionable, then please provide a summary of what needs to be done. Or even better: submit a pull request ;-).
I can submit a PR for this topic this week. This is lighting a fire under me to get back into contributing.