How to know the version of perl6/raku I am running? - raku

Trying the -v switch, I get the parrot svn revision:
$ perl6 -v
This compiler is built with the Parrot Compiler Toolkit, parrot revision 45822.
but how do I know the rakudo version, either a vx.xx or {some-git-hash}?
Thanks,

The special variable $*PERL may provide the hint
> $*PERL.compiler
rakudo (2018.04.1)
> $*PERL.compiler.^attributes
(Str $!id Str $!release Str $!build-date Str $!codename Str $!name Str $!auth Version $!version Blob $!signature Str $!desc)
> $*PERL.compiler.^methods'
(BUILD build-date verbose-config Str gist id release codename name auth version signature desc BUILDALL)
> $*PERL.compiler.name
rakudo
> $*PERL.compiler.version
v2018.04.1
> $*PERL.compiler.auth
The Perl Foundation
> $*PERL.compiler.build-date # This being the date it was built on my machine
2018-05-18T21:59:11Z
> $*PERL.compiler.verbose-config
...

Currently you can't know :(
There's a patch for that in RT that awaits review: http://rt.perl.org/rt3/Ticket/Display.html?id=73148 but so far it hasn't been applied yet.
Update: With a sufficiently new Rakudo, you get:
$ perl6 -v
This is Rakudo Perl 6, version 2010.06-212-g1086ff8
Copyright 2008-2010, The Perl Foundation
Where the thing after "version" is the git describe output.

perl6 -v now works. It provides the last monthly release, the number of commits since then, and the git hash.

Related

Project ERROR: Cannot run compiler 'g++'. Maybe you forgot to setup the environment whithin gitlab env

I've a strange phenomenom happening that I don't know how to investigate.
I hope someone already encountered this an can provide tips
I'm using gitlab CI to build some Qt based projects.
gitlab runner calls a script named build.sh that works just fine when I run it manually as "me" in my env dev.
However runner raises an error stating "Project ERROR: Cannot run compiler 'g++'. Maybe you forgot to setup the environment".
So I made sure g++ was available (g++ -version is OK) and in g++ is in PATH but pbm is still there.
here is part of the script where the problem resides and the investigation I performed
echo ">>>>>> now generating makefiles for ${PROJECT_FILE} <<<<<<"
export QTDIR=/usr/lib64/qt5
echo $QTDIR
echo QMAKESPEC is
qmake-qt5 -query QMAKE_SPEC
echo gcc version is
gcc --version
g++ --version
echo $PWD
whoami
$cmd_qMake -v
$cmd_qMake -makefile -o qMakefile ../src/${PROJECT_FILE}
echo PATH is $PATH
echo QMAKESPEC is
qmake-qt5 -query QMAKE_SPEC
echo gcc version is
gcc --version
g++ --version
and here is the output (sorry; this is in debug mode)
>>>>>> now generating makefiles for Communication.pro <<<<<<
+ export QTDIR=/usr/lib64/qt5
+ QTDIR=/usr/lib64/qt5
+ echo /usr/lib64/qt5
/usr/lib64/qt5
+ echo QMAKESPEC is
QMAKESPEC is
+ qmake-qt5 -query QMAKE_SPEC
linux-g++
+ echo gcc version is
gcc version is
+ gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ echo /root/builds/3188cf72/0/EGNOS_V3/AIV-P/AIV-P/Shared/Communication/.buildchain
/root/builds/3188cf72/0/EGNOS_V3/AIV-P/AIV-P/Shared/Communication/.buildchain
+ whoami
root
+ qmake-qt5 -v
QMake version 3.1
Using Qt version 5.9.2 in /usr/lib64
+ qmake-qt5 -makefile -o qMakefile ../src/Communication.pro
Project ERROR: Cannot run compiler 'g++'. Maybe you forgot to setup the environment?
+ echo PATH is /opt/gcc-7.3.0/bin:/usr/bin:/usr/sbin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin
PATH is /opt/gcc-7.3.0/bin:/usr/bin:/usr/sbin:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/bin
+ echo QMAKESPEC is
QMAKESPEC is
+ qmake-qt5 -query QMAKE_SPEC
linux-g++
+ echo gcc version is
gcc version is
+ gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ for target in '"${TARGETS[#]}"'
As you can see, g++ seems available un runner's root PATH
So why is qMake failing?
Thanks for your help
Zaluum
I had the same error sudo apt install build-essential worked for me.
Well, finally found it!
Turns out that the error message is not clear at all or at least subject to interpretation.
It was not an issue with gcc that could not be found. It was however a problem with my env.
Root user did not have /usr/local/lib in its LD_LIBRARY_PATH (when I had it).
The reason why is needed is unclear to me but I suspect this is something to do with libisl being necessary for GCC 7.3.0 which is my QMAKE_CC.
Hope this helps somebody
Zaluum
In most of the cases, this is a problem with environment settings - especially path to compiler/toolchain etc.
On Windows it concerns PATH environment variable's setting. For example - when you use minGW toolchain with g++ you should have PATH set e.g.
C:\Qt\Tools\mingw810_64\bin
However sometimes setting it in Windows Control Panel is insufficient, because other application (you have installed) could play with PATH and overrided it. So I recommend to everyone facing this issue and fired all found possible solution, first - to check if printing PATH in cmd (command line Windows tool) follows PATH you have set in Control Panel. If not you can try:
Find reason for PATH is different,
Check if it is not problem described here: https://stackoverflow.com/a/65163187/8389251
Add new Windows User (new account) - and run there Qt Creator and compilation. (Still ensure you have properly set PATH in Control Panel)

Probable version skew in pre-compiled xxx

I'm installing a package onto a virtual machine(ubuntu18.04).
Here are the instructions I used:
apt-get install perl6 && \
git clone https://github.com/ugexe/zef.git && cd zef && perl6 -I. bin/zef install . && \
/usr/lib/perl6/site/bin/zef install Shell::Command && \
PYTHON_CONFIG=/usr/bin/python3-config \
/usr/lib/perl6/site/bin/zef -v install https://github.com/eatingtomatoes/Inline-Python3.git --/test --debug
Following is the output:
....
===> Building [OK] for Inline::Python3:ver<0.1>
===> Installing: LibraryMake:ver<1.0.0>:auth<github:retupmoca>
===> Install [OK] for LibraryMake:ver<1.0.0>:auth<github:retupmoca>
===> Installing: Inline::Python3:ver<0.1>
===> Install [FAIL] for Inline::Python3:ver<0.1>: ===SORRY!===
Probable version skew in pre-compiled
'site#sources/95D204DDA68A3E05E891AA531EBED9270C46B3F7
(Inline::Python3::InstanceConverter)' (cause: no object at index 499)
===SORRY!===
Probable version skew in pre-compiled
'site#sources/95D204DDA68A3E05E891AA531EBED9270C46B3F7
(Inline::Python3::InstanceConverter)' (cause: no object at index 499)
When I executed perl6 -e "use Inline::Python3; say 'hi'" in shell, it reported:
===SORRY!===
Probable version skew in pre-compiled
'site#sources/95D204DDA68A3E05E891AA531EBED9270C46B3F7
(Inline::Python3::InstanceConverter)' (cause: no object at index 499)
The Inline::Python3 package is a perl6 package developped by myself. It runs well on my pc.
perl6 --version said:
This is Rakudo version 2018.03 built on MoarVM version 2018.03
implementing Perl 6.c.
I don't know what the 'version skew' is. How can I fix the error?
Following #jjmerelo's advice, using the latest compiler provided by rakudo-pkg solved the problem.

`Missing or wrong version of dependency` after recompiling nqp

I am trying to learn myself how to debug rakudo and nqp. So this is my first attempt:
cd $HOME/debug
git clone https://github.com/rakudo/rakudo.git
cd rakudo
perl Configure.pl --gen-moar --gen-nqp --backends=moar
make
make install # installs into ./install/bin
export PATH=${PWD}/install/bin:$PATH
export PATH=${PWD}/install/share/perl6/site/bin:$PATH
# Testing executable:
perl6 --version
# This is Rakudo version 2018.12-256-g9517c3779 built on MoarVM version 2018.12-36-g34fac5f4e
# implementing Perl 6.d.
#
# Now modifying an nqp file:
cd nqp
# Change a file: E.g. : vim src/HLL/Compiler.nqp
# I added a line after line 293 in src/HLL/Compiler.nqp:
# nqp::say("*** Debugging message: HLL::Compiler::command_eval() ***");
# and save it
make
make install
# Testing perl6 again..
perl6 --version
The last command now gives the following exception:
Unhandled exception: Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from 'src/Perl6/Pod.nqp')
at <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/Perl6/Pod.moarvm:<dependencies+deserialize>)
from src/vm/moar/ModuleLoader.nqp:47 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:load_module)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/Perl6/Actions.moarvm:<dependencies+deserialize>)
from src/vm/moar/ModuleLoader.nqp:47 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:load_module)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/Perl6/Grammar.moarvm:<dependencies+deserialize>)
from src/vm/moar/ModuleLoader.nqp:47 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:)
from src/vm/moar/ModuleLoader.nqp:40 (/home/hakon/debug/rakudo/install/share/nqp/lib/ModuleLoader.moarvm:load_module)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/perl6/runtime/perl6.moarvm:<dependencies+deserialize>)
h
So I thought, maybe I need to run make on rakudo also:
cd ..
make
but here make fails with:
/home/hakon/perlbrew/perls/perl-5.29.3/bin/perl5.29.3 tools/build/check-nqp-version.pl /home/hakon/debug/rakudo/install/bin/nqp-m
/home/hakon/debug/rakudo/install/bin/nqp-m tools/build/gen-cat.nqp moar src/vm/moar/ModuleLoaderVMConfig.nqp src/Perl6/ModuleLoader.nqp > gen/moar/ModuleLoader.nqp
/home/hakon/debug/rakudo/install/bin/nqp-m --module-path=blib --target=mbc --output=blib/Perl6/ModuleLoader.moarvm \
gen/moar/ModuleLoader.nqp
*** Debugging message: HLL::Compiler::command_eval() ***
Confused at line 2, near "*** Debugg"
at gen/moar/stage2/NQPHLL.nqp:811 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:panic)
from gen/moar/stage2/NQP.nqp:921 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:comp_unit)
from gen/moar/stage2/NQP.nqp:782 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:TOP)
from gen/moar/stage2/QRegex.nqp:2300 (/home/hakon/debug/rakudo/install/share/nqp/lib/QRegex.moarvm:parse)
from gen/moar/stage2/NQPHLL.nqp:2031 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:parse)
from gen/moar/stage2/NQPHLL.nqp:1951 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:execute_stage)
from gen/moar/stage2/NQPHLL.nqp:1984 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:run)
from gen/moar/stage2/NQPHLL.nqp:1976 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:)
from gen/moar/stage2/NQPHLL.nqp:1971 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:compile)
from gen/moar/stage2/NQPHLL.nqp:1666 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nqp:1889 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:evalfiles)
from gen/moar/stage2/NQPHLL.nqp:1849 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
from gen/moar/stage2/NQPHLL.nqp:1773 (/home/hakon/debug/rakudo/install/share/nqp/lib/NQPHLL.moarvm:command_line)
from gen/moar/stage2/NQP.nqp:4135 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:MAIN)
from gen/moar/stage2/NQP.nqp:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:<mainline>)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:<main>)
from <unknown>:1 (/home/hakon/debug/rakudo/install/share/nqp/lib/nqp.moarvm:<entry>)
make: *** [Makefile:457: blib/Perl6/ModuleLoader.moarvm] Error 1
A Rakudo build is statically "linked" against libraries in the NQP build used to produce it, and therefore Rakudo will need to be rebuilt after modifying NQP. Hashing is used to ensure that the wrong version of a dependency is never used; if this situation was not detected, there's a high chance of extremely strange failure modes.
The second failure is because the Rakudo build uses some NQP scripts to preprocess some source files, which are then fed to the NQP of Perl 6 compiler. It uses > to redirect the output into a file. Therefore, your debug output will be redirected into that file, and then - since it is not valid source code - cause a build error. The solution is to always produce debug output on stderr instead, for example using note.

makefile variable inside of ifeq block is not visible

I have a makefile:
SOURCES= helloworld.c
ifeq ($(OSNAME), linux)
# Object files needed to create library
OBJECTS=$(SOURCES:%.c=%.o)
endif
# Windows Microsoft C/C++ Optimizing Compiler Version 12
ifeq ($(OSNAME), win32)
OBJECTS=$(SOURCES:%.c=%.obj)
endif
#OBJECTS=$(SOURCES:%.c=%.o) #without this line print won't output anything
print:
#echo $(OBJECTS)
When I call make print (on linux and macOS), it prints empty line unless I uncomment the #OBJECTS=$(SOURCES:%.c=%.o) line.
Why is this happening? Arn't all variables global?
Hint 1):
You can print out every variable from make with the following command:
SOURCES= helloworld.c
$(info sources: $(SOURCES))
$(info osname: $(OSNAME))
$(info os: $(OS))
Hint 2)
As you can see from the output in linux it returns:
sources: helloworld.c
osname:
os:
you can see that OSNAME is not set on linux at all, so your check ifeq ($(OSNAME), linux) will always fail!
To get the OS information, checkout this link:
OS detecting makefile
I gave a test to your Makefile but to no avail. While it is possible that it should work in general, it does not seem to resemble other examples for testing OS. Hence I'm tempted to suggest that your conditionals, at least for Linux where I tested, do not evalute to true, hence the variable is not set.
Here is a rewritten example that seems to work on Linux:
SOURCES= helloworld.c
UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Linux)
# Object files needed to create library
OBJECTS=$(SOURCES:%.c=%.o)
endif
# Windows Microsoft C/C++ Optimizing Compiler Version 12
ifeq ($(OS),Windows_NT)
OBJECTS=$(SOURCES:%.c=%.obj)
endif
print:
#echo $(OBJECTS)
Output (for me on Linux):
db#vm1:~/projects/here> make
helloworld.o
This example was mostly inspired by the following gist:
https://gist.github.com/sighingnow/deee806603ec9274fd47

"Requires" entry in .spec file does not work

I was writing an .spec file for a rpm package and I'm having an issue.
I need to install that package with a specific version of another package.
Let's take a python package example. So, I write it:
Requires : bash, grep, python >= 2.6.7-4b
But, the package is installed even if the python package is in the 2.6.6 version.
If I remove python package, the system shows me that my package needs python 2.6.7.
Is there something wrong?
Output from rpm -q --provides python:
Distutils
python(abi) = 2.6
python-abi = 2.6
python-ctypes = 1.0.1
python-hashlib = 20081120
python-sqlite = 2.3.2
python-uuid = 1.31
python-x86_64 = 2.6.6-52.el6
python2 = 2.6.6
python = 2.6.6-52.el6
python(x86-64) = 2.6.6-52.el6
Output from rpm -qpR $yourpackage.rpm:
/bin/sh
python >= 2.6.7-4b
bash
grep
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
The ''Requires:'' tag is ignored unless you add ''Autoreq: no'' as well.
Newer versions of rpmbuild calculate the requirements automatically and ignore ''Requires:'' unless the feature is turned off.
I have run into this issue multiple times and it is worth noting that you should at first run rpmbuild without ''Autoreq: no'', note the autodetected dependencies, and add them to the ''Required:'' tag before the final run with ''Autoreq: no''.
Is also worth noting that the automatic detection of dependencies is a little buggy and has some issues with comments.
I packaged a perl script with a comment containing " ... then use a module ... " a while ago.
Autoreq detected that as being perl module "perl a" and added it to the dependencies making my rpm useless.