I am currently trying to get going with developing additional functionality for the MonetDB DBMS. I have been reading through the code and tried to debug the code using VSCODE which actually works fine. However, I encountered difficulties when trying to run tests that are already present in the repo using Mtest.py.
To come to the current point, I have forked the latest version of MonetDB (11.40.0) and proceeded with installing it on my ubuntu 20.04 by following the shipped debian documentation:
CONFIGURE_OPTIONS="-DCMAKE_BUILD_TYPE=Debug -DASSERT=ON -DSTRICT=ON"
cd build
cmake $CONFIGURE_OPTIONS
cmake --build .
cmake --build . --target install
The above statements install the applications in the default location. I have also tried to alter the installation direction using -DCMAKE_INSTALL_PREFIX flag. However, this lead to the same results and problems running the tests.
For running specific test cases I have tried the following two thing:
cmake: cmake --build . --target mtest
Mtest.py: Mtest.py sql/test/Tests/
Both attempts lead to the same console output:
Perl available, but MonetDB driver or DBI module not available
abort: there is no Mercurial repository here (.hg not found)
cannot write timeout message mserver5 --debug=10 --set gdk_nr_threads=0 --set mapi_listenaddr=all --set mapi_port=30201 --set mapi_usock=/var/tmp/mtest-16710/.s.monetdb.30201 --forcemito --dbpath=/usr/local/var/MonetDB/mTests
Mtest.py: ERROR: No output from mserver5 when checking for Bits, Modules & Threads!?
It states that the started mserver5 instance is not responding properly somehow. I have currently no clue how to tackle this issue. Can anyone tell me if I might missed out on something?
I have checked the build flags and the corresponding TESTING flag is set on default. Is there anything I messed up with mserver5 or I might have to configure separately?
Looking forward to hearing from you,
Martin
I finally found the reason for my issue with running MonetDB's tests. Thanks to #Joeri van Ruth for making playing around with mserver5 application.
The problem was that I commented in the definition of _SQL_COMPILE in the file sql_execute.sql in order to view the generated MAL code and other debug output generated along compilation. The problem with this is that it calls mnstr_printf and is printing to stdout. This debug output to somehow interferes the required communication and mserver5 cannot respond correctly.
Related
I am trying to use the latest version of the appImage-builder because appimages of my application built with the old version of appImage-builder do not run on ubuntu 22.04 anymore. So I got the order to try and see if it works with the new appImage-builder.
Currently (June 2022), only versions below 1.0 which are based on ubuntu 18.04 are available on docker (which we previously used to build our appimage).
The newer versions are available via github (https://github.com/AppImageCrafters/appimage-builder/releases).
However, I seem to be unable to execute:
appimage-builder --generate
or
appimage-builder --recipe AppImageBuilder.yml
Is there any documentation available on how to correctly use the .appimage version of appImage-builder? All I could find in https://appimage-builder.readthedocs.io/en/latest/ seems to refer to the docker version or a manually built version of appImage-builder.
Depending on the error message you get, there could be a couple of issues at play here.
If you got an error related to FUSE, then you need to install the libfuse2 package with apt install libfuse2. AppImages rely on libfuse2, but Ubuntu has stopped including it since 22.04, in favor of libfuse3.
If you get an error related to "file not found", then it could be that you do not have AppImageLauncher installed. Sadly, with type 2 AppImages the design decision was taken to modify the ELF header of the executable with 3 magic bytes at offset 8 of the executable. This means that Linux linkers will not run the file. AppImageLauncher actually copies the file to a temporary directory and zeroes out the magic number in order to be able to execute it.
A good starting point for debugging issues like this is to run the strace command, which will let you see which system call likely cause the error. Keep in mind that if you try to execute a file and you get File not found, it might mean that the linker specified by the file can not be found on the system or the ELF header is not valid. You can also run the executable by using the linker directly, which might give you more clues. For example with: /lib64/ld-linux-x86-64.so.2 <NAME-OF-YOUR-EXECUTABLE>.
Context: I am currently working on a research project to run an end to end simulation of a 5G cellular network with simu5G. I need help with the installation of Omnet++6.0pre10(or pre 11) from the command line (I don't have access to a gui). My operating system is Ubutnu 18.04.5 LTS
I am new to Omnet++ and need help with installation of Omnet++6.0pre10 (or pre11) from the command line.
I have tried looking at the manual, but the latest version is always the 5.6.1 version:
https://doc.omnetpp.org/omnetpp/UserGuide.pdf
and the steps I have taken are:
forking from the Omnetpp github repository
cloning the forked repository to the local machine
But when I try the first step of . setenv it gives me the following error:
Error: '$dir' does not look like an OMNeT++ root directory
which is the error associated with if the directory is really pointing to an omnet++ installation dir (if you look at the bash code in setenv file)
Please help in:
Advise on how to fix this error with the setenv script
how to actually install omnet++6.0pre10(or 11) through the command line and how that differs to the latest user guide (user guide 5.6.1)
Best wishes and thank you so much
You have probably forgotten creating configure.user mentioned in Instalation description, i.e.:
cd omnetpp
cp configure.user.dist configure.user
Checking out the master version of OMNeT++ is not the best choice, especially if you are doing research. I would advise to use instead the omnetpp-X.y-src-core.tgz version which does not have the IDE. However also the omnetpp-x.y-src-linux.tgz version would do fine as long as you disable the OSG, OSG_EARTH and QTENV components in configure.user, before running ./configure
Question: What are the steps to install a kubectl plugin on Windows?
I have written a plugin standalone binary that I would like to invoke from within kubectl (following the instructions in https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/)
The documentation for installation states to perform the following steps:
"A plugin is nothing more than a standalone executable file, whose name begins with kubectl-. To install a plugin, simply move this executable file to anywhere on your PATH."
This works fine on Mac and Linux, but performing those instructions on Windows does not seem to work. Running "kubectl plugin list" does not list my plugin and I cannot invoke it from within kubectl. I even tried adding my binary to the .kube directory autogenerated by kubectl, and it does not detect the plugin.
Several discussions on github reference this issue, without providing a response of how to install a kubectl plugin on Windows (ex: https://github.com/kubernetes/kubernetes/issues/73289). And after performing a lengthy google/stackoverflow search, there don't seem to be any tutorials/solutions that I (or my teammates) could locate. Any help would be much appreciated! Thank you.
In my case I don't have an issue with installing a plugin on Windows 10 machine (by simply including it on my PATH). Here is the output of 'kubectl plugin list':
c:\opt\bin>kubectl plugin list
The following kubectl-compatible plugins are available:
c:\opt\bin\kubectl-getbuildver.bat
- warning: c:\opt\bin\kubectl-getbuildver.bat identified as a kubectl plugin, but it is not executable
c:\opt\bin\kubectl-hello.exe
c:\opt\bin\kubectl-helloworld.p6
- warning: c:\opt\bin\kubectl-helloworld.p6 identified as a kubectl plugin, but it is not executable
error: 2 plugin warnings were found
Instead I'm encountering a known github issue: 'not supported by windows' error, while invoking my plugin with kubectl (v1.13.4).
c:\opt\bin>kubectl hello
not supported by windows
c:\opt\bin>kubectl-hello.exe
Tuesday
*kubectl-hello.exe - is console application written in csharp. I tried also to use Windows batch file and Perl6 program as plugins, but none of these worked out on Windows.
I think only .exe file extensions are considered as executables by kubectl when it searches for plugins in the $PATH when running in Windows environment.
I tested by creating a simple HelloWorld App as a single file executable, added it to my system's $PATH and it got picked up and executed correctly.
kubectl krew like brew to manage the kubectl plugin. You can try it. It supports Window.
https://github.com/kubernetes-sigs/krew
I encountered the problem that I wanted to have a debug, then I wanted to build a debug version of tensorflow, using the following command:
bazel build --compilation_mode=dbg -s //tensorflow/tools/pip_package:build_pip_package
but it will trigger the longtime link in protobuf for almost oneday, and still not finished.
and my intension is to build some other package which is used by tensorflow with debug mode, could I configure the bazel build file to get some debug package separately?
To understand the issue better, try running the neverending action manually:
start the debug build, wait for it to get stuck in the protobuf linking action
interrupt the build (Ctrl+C)
run the build again with the -s flag, so Bazel shows the command line it executes (you could've ran step 1. with the -s flag, but then there's a lot more output and it's harder to find the right information)
interrupt the build again
cd into the directory shown in the by command and set environment variables
try running the command that failed (you may need to change the output paths because they are sometimes not user-writable) and see if it still never finishes
What you just did is running the same command Bazel was running and getting stuck on. If the command is stuck in this manual mode too, then the error might be with the linker (I doubt this is the case though). But if it succeeds, then the problem is with Bazel.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll