`Missing or wrong version of dependency` after recompiling nqp - raku

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.

Related

CMake build fails with Xcode 12 and CMAKE_IOS_INSTALL_COMBINED=YES

EDIT This is a known CMake issue.
With Xcode 11 (specifically Xcode 11.2.1) I used to be able to cross-compile my project for iOS with this command:
cd /path/to/project
mkdir build
cd build
cmake .. -G Xcode -DCMAKE_SYSTEM_NAME=iOS \
"-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" \
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
-DCMAKE_IOS_INSTALL_COMBINED=YES \
-DCMAKE_INSTALL_PREFIX=install
cmake --build . --config Release --target install
This created a build with two slices, one slice for the arm64 architecture (for running on a real device) and one slice for the x86_64 architecture (for running in a simulator on an Intel-based dev environment).
After upgrading to Xcode 12 (specifically Xcode 12.3) this no longer works. The build consistently fails with this error message (line break added by me):
error: unable to attach DB: error: accessing build database "/path/to/project/build/ios/build/XCBuildData/build.db":
database is locked Possibly there are two concurrent builds running in the same filesystem location.
The issue seems to be a post-build rule that CMake creates for the install target. In that post-build rule a second build is initiated while the first one is still in progress.
if test "$CONFIGURATION" = "Release"; then :
cd /path/to/project/build/ios
/usr/local/Cellar/cmake/3.19.2/bin/cmake -DBUILD_TYPE=$CONFIGURATION -DEFFECTIVE_PLATFORM_NAME=$EFFECTIVE_PLATFORM_NAME -P cmake_install.cmake
fi
The build succeeds when I no longer set CMAKE_IOS_INSTALL_COMBINED to YES, but then the resulting build only contains one slice (arm64 in my case, presumably because this is the first architecture that is listed in CMAKE_OSX_ARCHITECTURES).
I'm considering making a separate build for each architecture, and then stitching the slices together manually. Before I go down that road, has anyone been able to find a more elegant solution?
Environment: macOS 11.1, Xcode 12.3, CMake 3.19.2
The CMake 3.19 release notes contain this hint:
The Xcode generator now uses the Xcode “new build system” when generating for Xcode 12.0 or higher. See the CMAKE_XCODE_BUILD_SYSTEM variable. One may use -T buildsystem=1 to switch to the legacy build system.
The workaround, for the moment, is therefore to add the -T option to the build system generation command line:
cmake .. -G Xcode -T buildsystem=1
-DCMAKE_SYSTEM_NAME=iOS \
"-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" \
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO \
-DCMAKE_IOS_INSTALL_COMBINED=YES \
-DCMAKE_INSTALL_PREFIX=install
This should work as long as Xcode still supports the legacy build system. The Xcode 12 Release Notes have this to say on the matter:
The legacy build system is deprecated, and will be removed in a future release. (62742902)
So the -T buildsystem=1 option can only be considered a temporary workaround.

How to fix libtool: undefined symbols not allowed in x86_64-pc-msys shared

I am trying to build heimdal package for msys2. To my dismay, during linking of the first constituent library, roken, dlls fail to be built, and that causes sort of a chain reaction further on.
The only message i get is:
libtool: undefined symbols not allowed in x86_64-pc-msys shared ... only static will be built
however, there is no information provided on what symbols are undefined. How can i find that out?
If i turn on output of commands wuth make V=1 i get libtool command that links from a large numbert of .lo files. If i try to run gcc over them (copying command from there), it does not recognize them as anything.
I am trying to follow instructions as outlined in msys2 package build script for heimdal.
On Windows building a shared library while allowing undefined symbols is not allowed.
Try to build with the -Wl,-no-undefined linker flag, for example by adding LDFLAGS="-Wl,-no-undefined" to the ./configure command.
If that didn't work try this after ./configure and before make:
sed -i.bak -e "s/\(allow_undefined=\)yes/\1no/" libtool
If you already had a failed build earlier you should also clean up any .la files like this before running make again:
rm $(find -name '*.la')

Installation of Perl6 fails, no registered operation handler

I'm trying to install Perl6 thus:
perl Configure.pl --backend=jvm --gen-nqp
and then the traditional make & make install
the latter-most of which gives this error:
== Installing modules for JVM
cd modules/zef && sh -c "PATH='/illumina/runs/Scripts/perl6/rakudo-star-2018.10/install/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/illumina/runs/RNASeq/stringtie-1.3.3b.Linux_x86_64:/illumina/runs/RNASeq/subread-1.6.0-Linux-x86_64/bin:/illumina/runs/RNASeq/STAR-master/bin/Linux_x86_64:/illumina/runs/RNASeq/hisat2-2.1.0:/home/703404669/Scripts/vcftools-vcftools-ea875e2/src/cpp:/illumina/runs/RNASeq/FastQC:/home/703404669/.local/bin:/home/703404669/bin' /illumina/runs/Scripts/perl6/rakudo-star-2018.10/install/bin/perl6-j -Ilib bin/zef install ."
===SORRY!===
Error while compiling op nativecallinvoke, no registered operation handler
make: *** [modules-install-j] Error 1
I am still a newbie with Perl6, I have no idea how to deal with this error, and it doesn't show up on search engines.
How can I get past this error to install perl6?
The JVM backend has not received quite the amount of love that the MoarVM backend has and is known to have problems (although I'm surprised to see it is this bad).
Is there a reason why you would not like to use the MoarVM backend? If you don't have a reason, you could try changing the --backend=jvm parameter to --gen-moar, which would then fetch and build the MoarVM backend for you automagically.

How can I figure out why Linenoise is failing to install?

This is on 64-bit Windows 10 Pro with MSVC 2015. This question has a long body because I want to give full information up front, but the actual question is rather straightforward:
How can I get panda to keep the working directory around (like cpanmdoes) after an install failure so I can diagnose what went wrong?
As you can see from the log below, linenoise.dll seems to be created in the right place, but come install time, it is nowhere to be found.
The .panda-work directory in %TEMP% is gone.
I just built Rakudo from source by doing
git clone git://github.com/rakudo/rakudo.git
cd rakudo
set CFLAGS=/O2 /favor:INTEL64 /Qpar
perl Configure.pl --gen-moar --gen-nqp --backends=moar --prefix=c:/opt/perl6
nmake test
nmake install
nmake spectest ← The number of failures has gone up since the last time I tried this, but that's not related to my question
Then I installed panda by doing:
git clone --recursive git://github.com/tadzik/panda.git
cd panda
perl6 bootstrap.pl
which worked.
Then I did
panda install Task::Star
I got a test failure:
==> Building NativeHelpers::Blob
==> Testing NativeHelpers::Blob
t/00-trivial.t ..
Dubious, test returned 5 (wstat 1280, 0x500)
Failed 1/1 subtests
but I force installed that because I wanted to get to as complete an install as possible as quickly as possible.
So, forging ahead, I hit this:
C:\Users\...\Temp> panda install Linenoise
==> Fetching Linenoise
==> Building Linenoise
Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
cl -c /nologo /MT /Ox /GL /DNDEBUG /DWIN32 /DAO_ASSUME_WINDOWS98 /O2 /favor:INTEL64 /Qpar /Folinenoise.obj linenoise.c
linenoise.c
perl6 -e "mkdir 'resources'; mkdir 'resources/libraries'"
link /dll /nologo /LTCG shell32.lib ws2_32.lib mswsock.lib rpcrt4.lib advapi32.lib psapi.lib iphlpapi.lib userenv.lib /out:resources/libraries/libline
noise.dll linenoise.obj
Generating code
Finished generating code
cl /Foconstant-helper /nologo /MT /Ox /GL /DNDEBUG /DWIN32 /DAO_ASSUME_WINDOWS98 /O2 /favor:INTEL64 /Qpar constant-helper.c
constant-helper.c
Generating code
Finished generating code
perl6 fill-constants.pl lib/Linenoise.pm
==> Testing Linenoise
==> Installing Linenoise
Failed to open file C:\Users\...\Temp\.panda-work\1483278033_1\resources\libraries\linenoise.dll: no such file or directory
in any at C:\opt\perl6/share/perl6/runtime/CORE.setting.moarvm line 1
in block at C:\opt\perl6\share\perl6\site\sources\85367160D11E565B2D089507C79BC309215430D6 (Panda::Installer) line 61
in sub indir at C:\opt\perl6\share\perl6\site\sources\24811C576EF8F85E7672B26955C802BB2FC94675 (Panda::Common) line 20
in method install at C:\opt\perl6\share\perl6\site\sources\85367160D11E565B2D089507C79BC309215430D6 (Panda::Installer) line 42
in method install at C:\opt\perl6\share\perl6\site\sources\582CB7486602954A4601BDCE5A0EAC54B05DA58A (Panda) line 190
in method resolve at C:\opt\perl6\share\perl6\site\sources\582CB7486602954A4601BDCE5A0EAC54B05DA58A (Panda) line 263
in sub MAIN at C:\opt\perl6\share\perl6\site\resources\1C71F7B377C6F2C6C4707E3C25016AA25A2926B1 line 20
in block at C:\opt\perl6\share\perl6\site\resources\1C71F7B377C6F2C6C4707E3C25016AA25A2926B1 line 165
Actually thrown at:
in method throw at C:\opt\perl6/share/perl6/runtime/CORE.setting.moarvm line 1
in any at gen/moar/Metamodel.nqp line 3072
in block at C:\opt\perl6\share\perl6\site\sources\85367160D11E565B2D089507C79BC309215430D6 (Panda::Installer) line 61
in sub indir at C:\opt\perl6\share\perl6\site\sources\24811C576EF8F85E7672B26955C802BB2FC94675 (Panda::Common) line 20
in method install at C:\opt\perl6\share\perl6\site\sources\85367160D11E565B2D089507C79BC309215430D6 (Panda::Installer) line 42
in method install at C:\opt\perl6\share\perl6\site\sources\582CB7486602954A4601BDCE5A0EAC54B05DA58A (Panda) line 190
in method resolve at C:\opt\perl6\share\perl6\site\sources\582CB7486602954A4601BDCE5A0EAC54B05DA58A (Panda) line 263
in sub MAIN at C:\opt\perl6\share\perl6\site\resources\1C71F7B377C6F2C6C4707E3C25016AA25A2926B1 line 20
in block at C:\opt\perl6\share\perl6\site\resources\1C71F7B377C6F2C6C4707E3C25016AA25A2926B1 line 165
The Build.pm file for Linenoise is simply not written correctly. They are hard-coding the 'lib' prefix to the library name while also trying to use the platform library name guessing mechanism in another part. If it wants to use $*VM.platform-library-name then it needs to generate a file named linenoise.dll, not liblinenoise.dll
I'm also not sure that Linenoise works on windows even if it did install.
You should probably be using zef instead of panda. If you were, you could view the working directory used at ~/.zef/store/p6-linenoise.git

Problems adding DKMS support to kernel module

I'm trying to add DKMS support in a kernel module i'm working on.
I have placed the kernel module source with a static lib to be linked against in the following directory:
/usr/src/dpx/1.0
With the following files:
dkms.conf
Makefile
dpxmtt.c
lib.a
dkms.conf file is like this:
MAKE="make"
CLEAN="make clean"
BUILT_MODULE_NAME=dpx
BUILT_MODULE_LOCATION=src/
DEST_MODULE_LOCATION=/kernel/drivers/input/touchscreen
PACKAGE_NAME=dpxm
PACKAGE_VERSION=1.0
REMAKE_INITRD=yes
And the makefile is like this:
EXTRA_CFLAGS+=-DLINUX_DRIVER -mhard-float
obj-m += dpx.o
dpx-objs:= dpxmtt.o ../source/lib.a
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
The ../source/lib.a is an hack since when the makefile is invoked by the dkms building system it was saying that it couldn't be found in directory (the build directory), but since it was being copied to the source directory, i'm referencing it relatively.
When I call
sudo dkms build -m dpx -v 1.0
The result is almost perfect:
santos#NS-PC:~$ sudo dkms build -m dpx -v 1.0
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area....
make KERNELRELEASE=3.0.0-14-generic....
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
Consult the make.log in the build directory
/var/lib/dkms/dpx/1.0/build/ for more information.
nsantos#NS-PC:~$
And the content of the log file is:
DKMS make.log for dpx-1.0 for kernel 3.0.0-14-generic (i686)
Thu Jan 19 11:07:54 WET 2012
make -C /lib/modules/3.0.0-14-generic/build M=/var/lib/dkms/dpx/1.0/build modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-14-generic'
CC [M] /var/lib/dkms/dpx/1.0/build/dpxmtt.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.o
Building modules, stage 2.
MODPOST 1 modules
CC /var/lib/dkms/dpx/1.0/build/dpx.mod.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-14-generic'
The module was built correctly but it ends with the error:
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
And I don't know what it means. Does anybody know?
Using:
$(shell uname -r)
in the Makefile it might be also wrong! The "shell uname -r" refers to the currently running kernel, but the main reason to use the dkms it's because it offers an automated method to recompile the kernel modules that reside outside of the kernel tree for every newly installed kernel. What i mean is that the Makefile might refers to a different kernel which the dkms is building the module for.
Use:
${kernelver} instead.
I had a similar problem. I think your BUILT_MODULE_LOCATION is set incorrectly to the src directory. It should be set in your example to the current directory, or you can just omit this variable and dkms would default to the current directory.