Using this link I created a container and after getting some packages, I want to start a qtcreator 4.0.1 on it. I use a ssh connection to connect to the container. After launching qtcreator I get an error such as this:
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.
Reinstalling the application may fix this problem.
I installed all prerequisites packages as listed here but still the problem is remained.
I must mention that I am using a privileged container in opposite of the link.
xcb listed as available plug-ins but it does not run. Is there any suggestion to get around this bug?
This answer has the main solution. In my case I find the libqxcb.so in path /path_to_qt/plugins/platforms/ and after running ldd command on it I found that it has not one of its dependency libEGL.so after install this package using sudo apt install libegl-mesa0-dev I could run qtcreator.
Related
I've been working with AWS lambdas for a few months. I was working with a lambda and it was fine at the end of the day. I came back to work on it the next day, and I can't get Visual Studio to even start the application using the Mock Lambda Test Tool.
I ended up creating an empty lambda that just returns the input (the standard project code that AWS gives you as a template) and that won't even run. I hit the play button to star the Mock Lambda Test Tool, it looks like it will run for a couple seconds, then it closes down. The command window does not even pop up.
This is the code from the template project.
public string FunctionHandler(string input, ILambdaContext context)
{
return input?.ToUpper();
}
This is all I get in the output window of VS:
The target process exited without raising a CoreCLR started event.
Ensure that the target process is configured to use .NET Core. This
may be expected if the target process did not run on .NET Core. The
program '[16700] dotnet-lambda-test-tool-2.1.exe: Program Trace' has
exited with code 0 (0x0). The program '[16700]
dotnet-lambda-test-tool-2.1.exe' has exited with code -2147450726
(0x8000809a).
I have tried re-installing the AWS toolkit, and also tried re-installing Visual Studio. This is an issue with VS 2017 and VS 2019. I just installed 2019 to see if that would fix the issue. Any help would be appreciated.
I came to this question having the very same issue. After installing AWS Toolkit I found that the lambda test tool was not installed and therefore I got the same error just as the OP. The only difference is that I was targeting .Net Core 3.1 and therefore I needed amazon.lambda.testool-3.1. However this answer should work for both scenarios.
Unfortunately I did not have the same luck as the OP of having a nice co-worker that could give me the files I needed. So, if this is also your case please continue reading.
In the official project site, which can be found here, there are the instructions to install the tools. It also says that installing the latest version of AWS Toolkit should be enough to have the tools installed (it was not in my case and probably in yours).
It says that in order to install the tools you should run the following commands:
dotnet tool install -g Amazon.Lambda.TestTool-3.1
or
dotnet tool install -g Amazon.Lambda.TestTool-2.1
depending on which tool you need.
However, running these commands fails with the following message:
The tool package could not be restored.
Tool 'amazon.lambda.testtool-2.1' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
And since the project is still in preview I just had to find the latest stable version in order to specify it in the command. For .net core 3.1 here is the nuget site, there I found version 0.10 to be the latest, so the command should look like:
dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1
I have faced the same issue and when i tried to install dotnet-lambda-test-tool-3.1.exe using command prompt I got this issue:
Failed to create shell shim for tool 'amazon.lambda.testtool-3.1': Command 'dotnet-lambda-test-tool-3.1' conflicts with an existing command from another tool.
Tool 'amazon.lambda.testtool-3.1' failed to install.
And I did the following to fix issue
Deleted the dotnet-lamda-test-tool-3.1.exe from the installed folder (C:\Users%USERNAME%.dotnet\tools\dotnet-lambda-test-tool-3.1.exe)
Run dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1 on cmd.
I have faced the same issue and got errors like "dotnet-lamda-test-tool-2.1.exe has exited with code.."
I did the following to fix the issue
Removed the dotnet-lamda-test-tool-2.1.exe from the installed folder
(C:\Users%USERNAME%.dotnet\tools\dotnet-lambda-test-tool-2.1.exe)
Removed the [amazon.lambda.testtool-2.1] folder as well
(C:\Users%USERNAME%.dotnet\tools\tools.store\amazon.lambda.testtool-2.1)
Installed dotnet tool from Developer command prompt using the command
[install -g Amazon.Lambda.TestTool-2.1]
Run the project. It is working
I have seen this issue many time on my system with dotnet-lambda-test-tool-6.0. Only one fix work for me
Remove dotnet-lambda-test-tool-6.0.exe from C:\Users\username.dotnet\tools
Open Command prompt from C:\Users\username.dotnet\tools
run command dotnet tool install -g Amazon.Lambda.TestTool-6.0
For anyone else that hits this same issue, it had to do with the the AWS toolkit install. I did not modify it, but somehow it was no longer working. I tried un-installing and re-installing, but it was still having issues running it. A co-worker sent me the exe and subdirectory that was setup on his machine under C:\Users\%user%.dotnet\tools. The exe is located in this directory, and there is another folder under .store for amazon.lambda.testtool-2.1. That directory had different folders and files than what I was able to install. So I copied in what he had and it worked. There might be a profile file associated to the tools install that points to these folders and files that might need to be modified. Since I was able to fix it with this, I didnt look any further into that.
I had the same issue with my .NET 6.0 lambda project. I installed the tool by executing dotnet tool install --global Amazon.Lambda.TestTool-6.0 --version 0.12.6 as suggested on https://www.nuget.org/packages/Amazon.Lambda.TestTool-6.0
Just ensure it is installed at %USERPROFILE%\.dotnet\tools\dotnet-lambda-test-tool-6.0.exe
I got the same issue with VS2019 with lambda design in 3.1 version and in Output window getting error
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
Then checked the folder having multiple version of lambda-test-tool in path
C:\Users{username}.dotnet\tools
I removed all the lambda-test-tool and installed the required tool only with version 3.1 by command in developer command prompt:
dotnet tool install -g --version 0.10 Amazon.Lambda.TestTool-3.1
Then I can able to debug the lambda
I'm trying to install Yesod through cabal on my HP computer, but the building process fails when shakespeare library gets the turn. MSYS2+MinGW in the path, the rest actually works. What could be the issue? I have my suspicions that it might be due to the x64 processor I have, but not sure.
Tried installing globally with runhaskell, but same story.
C:\Users\Ivan Kretov>cabal install shakespeare
Warning: The install command is a part of the legacy v1 style of cabal
usage.
Please switch to using either the new project style and the new-install
command or the legacy v1-install alias as new-style projects will become
the default in the next version of cabal-install. Please file a bug if
you cannot replicate a working v1- use case with the new-style commands.
For more information, see: https://wiki.haskell.org/Cabal/NewBuild
Resolving dependencies...
Starting shakespeare-2.0.20
Building shakespeare-2.0.20
I am using JetBrains GoLand and I am trying to debug my go file and I am getting the following error:
decoding dwarf section info at offset 0x0: too short
I tried to find an answer here at StackOverflow but unfortunately, I didn't get any solution.
GoLand ships with a bundled version of Delve. Update to 2018.2.2 and it should work. If you need to do remote debugging, then you need to update your Delve installation on/for the target machine as well (make sure you compile it with Go 1.11).
Edit:
There are two more possible cases where this issue can appear:
the application was compiled with all the debugging flags turned off and the additional debugging information stripped
the application uses the standard library "plugin" package, which is known to cause an issue in the Go compiler. This will be fixed in Go 1.12.
I would like to share my experience here too as it may be helpful for community, I made it works by doing the following:
Update Goland to 18.3
Also, in case if you have Mac, you should run xcode-select --install
In case if you had delv already installed inside GOPATH/bin, remove it and re-install it again by following instructions here
For my Mac the problem is related to the dlv package as installed by Golang plugin.
Install delv and,
check the path of dlv as executed by IntelliJ (in the console).
Go to this directory
($HOME//Library/Application Support/IntelliJIdea2017.3/intellij-go/lib/dlv/mac)
and rename dlv to any other name. Get the right dlv executable by using
which dlv (/usr/local/Cellar/go/1.11.1/libexec/bin/dlv for my computer)
and add a symbolic link
(ln -s /usr/local/Cellar/go/1.11.1/libexec/bin/dlv dlv).
After hours of effort, I was able to find the issue. It was due to Golang Plugin which is deprecated and was not compatible with IntelliJ IDEA 2018.2.2 (Ultimate Edition).
I uninstalled the plugin and reinstall the IntelliJ.
Hope this also helps to above solutions.
I need sbt version 0.13.x for a course in Scala and I am having difficulties installing it. I tried with the brew install sbt#0.13 command, but when I then check with sbt about it gives a message No such file or directory.
However, if I again try and do brew install sbt#0.13, it gives Warning: sbt#0.13 0.13.16 is already installed, although sbt about does not find anything.
In addition to that, I tried installing the latest version of sbt with brew install sbt and then manually changing the version each of my projects is using by entering sbt.version=0.13.12 in a given build.properties file. This seemed to work initially, when I check with the terminal the version of sbt inside the project. However, I am still not able to import already existing projects.
Finally, I downloaded the version from http://www.scala-sbt.org/download.html but then I need to do some corrections to my PATH from what I've read online and I am not sure what that means.
So, I would be grateful if someone could help me with the installation of an older version.
The way sbt works is that it will look in project/build.properties for the sbt version to use to build your project. So the way you described - installing the latest sbt and set the version you want to use for the build in project/build.properties - should work just fine.
Regarding
not able to import already existing projects
these existing projects also should have project/build.properties indicating the sbt version.
Note that even with installing 0.13.12 locally, when building your project sbt will still use the version specified in project/build.properties, it will just download it as necessary.
If you absolutely want to run a specific version from the command line, as you already discovered, you can download it. Regarding updating your PATH - PATH is an environment variable that tells your command line where to look for executable files. It's a list of directories, so if you unpacked the downloaded file in say "$HOME/tools", you have so say something like export PATH=$HOME/tools/sbt/bin:$PATH. See https://www.cyberciti.biz/faq/appleosx-bash-unix-change-set-path-environment-variable/ for a more detailed description.
I’ve been experiencing a nasty issue with profiling on Windows. But first, the context of setup:
I created a shared sandbox in ~/dev/foo_shared: cabal sandbox init --sandbox=.
I created a sandbox in ~/dev/foo using the shared sandbox above: cabal sandbox init --sandbox=~/dev/foo_shared
I installed all the dependencies with profiling enabled: cabal install --only-dependencies --enable-library-profiling --enable-executable-profiling
I configured the foo package so that it includes profiling RTS: cabal configure --enable-profiling --enable-executable-profiling
I tried to build with cabal build
Everything builds up correctly, but doesn’t link. I then rebuilt with cabal build -v3, and this is the linker part (the most interesting part):
c:/program files/haskell platform/2014.2.0.0/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lHSrts_debug_p
I googled that, and IIRC, it’s because I lack the profiling library for the GHC’s RTS. I never found it for Windows :( Last information, I’m on Windows 10, not sure it helps though.
Problem solved. The issue is due to the fact I’m using -debug on the command line interface to GHC. I’ve been told -debug and -p are not compatible, hence the error.