When I tried to run a CUDA example (from /usr/local/cuda/samples/) many errors appeared from missing libraries, including libGLU.so, libX11.so, libXi.so and many others. There where installed, but re installing didn't have any effect. Of course compilation couldn't continue.
Some libraries where shown as optional during CUDA installation (by manual installation after finished CUDA installation) and I did not care about them. I didn't keep any log so I lost that information.
I searched for missing symbolic links and also wrong versions of the libraries, but nothing happened.
After a lot of research I found that the libraries are in their devel packages. So I had to install the following (with yum):
libXi-devel
mesa-libGLU-devel
libXmu-devel
libX11-devel
freeglut-devel
Now, this brought a new problem with libGLU at compilation time because of the installation of mesa-libGLU-devel (I was trying with the examples) because the reference to libGL.so is no longer there, so I had to reinstall the NVIDIA drivers, which corrected the broken link.
After that the compilation of examples worked. I found the second part of the solution here
Related
I'm trying to initiate astro. When i don't choose a framework i get this error although i have git installed and fully working. Any help will be highly appreciated.
√ Which frameworks would you like to use? »
> Copying project files...
could not find commit hash for latest
This seems to be an issue with degit. Please check if you have 'git' installed on your system, and install it if you don't have (https://git-scm.com).
If you do have 'git' installed, please file a new issue here: https://github.com/withastro/astro/issues
It depends on your OS and environment.
For instance, withastro/astro issue 2144 reports the exact same error message, but on Windows, using Linux on WSL2 (Ubuntu 20.04.3 LTS).
Double-check your %PATH%/$PATH in your execution environment.
Update Oct. 2022, ten month later: withastro/astro issue 2144 is reported closed with the workaround by Matej Bunček:
As I was researching this seems to be a general issue with NPM for those who uses SSH.
There's an open issue here: npm/cli#2610 which is still far from being resolved and it's a huge thread.
Some folks might be interested in these workarounds to get it working.
git config --global url."https://github.com/".insteadOf git#github.com:
git config --global url."https://".insteadOf git://
Also I've tried yarn, npm and pnpm, all of them seems to have same problem so I believe it's core problem of node.
Also both npm 6 and 7 are not working.
Not a direct solution to your error message, but a general solution for those kinds of errors:
I would recommend doing the development inside docker containers, so called devcontainers.
Since you will develop in separate and isolated environments containing only the project's minimum dependencies and tools, it is a lot less likely to face OS specific issues in general.
Here are some resources to get started:
https://code.visualstudio.com/docs/remote/containers
https://microsoft.github.io/code-with-engineering-playbook/developer-experience/devcontainers/
https://github.com/microsoft/vscode-dev-containers
I want to install FEATool on Octave 4.2.2. Therefore, I went through these steps:
Downloading it.
Trying pkg install FEATool-Multiphysic.tar.gz in Octave command-line interface.
Octave returns this error:
COPYING file missing.
Neither GitHub nor FEATool provides any installation file for Octave or instructions about doing it.
Therefore, the question is:
How to install FEATool on Octave (Ubuntu 18.04)?
Following a quick preliminary check, it seems that the FEATool is no longer available or compatible with Octave since FEATool v1.10.
While there was no explicit announcement for this either on their blog or changelogs, according to the main author of the software (as elicited below), this seems to relate to overhead involved in supporting Octave on top of Matlab. Furthermore, as the company seems to have effectively chosen (for their own good reasons, I'm sure) to intentionally follow a direction that explicitly breaks Octave functionality, it cannot be expected to work on this platform even as unsupported software. Therefore the answer to your question is that "no you can no longer install this tool on octave (ubuntu or otherwise)".
Evidence that this software is no longer available for, or compatible with Octave:
Mentions to Octave in the documentation from v1.8 have now disappeared and are exclusive to Matlab (with extra effort towards Matlab backwards compatibily)
The .tar.gz package is no longer an Octave-compatible package.
The main code relies on .p files, which obfuscate the code and are unsupported in Octave
Past releases and source code have disappeared and are no longer available for download, both from sourceforge, official website, and github. Therefore it is not possible to download the octave-compatible v1.8 of the tool either.
I am currently having an issue with Octave install in Archlinux. I am not able to load the current version of Octave 4.2.1 in Arch. It shows the following message -
/usr/lib/octave/4.2.1/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
This problem with libgfortran.so.3 is not rare. Here are two similar problems happening in R 1 and 2. If somebody using Octave on Archlinux came across this issue, can you share how to resolve it. Thanks.
From the comments it became apparent that the solution from the referenced question R v3.4.0-2 unable to find libgfortran.so.3 on Arch needs to be appended, because the way the older GCC versions will be typically installed in Arch Linux is in a different path.
So, one must find, where the older version is installed, like
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgfortran.so.3
(depending on the exact GCC version)
and then add the version to LD_LIBRARY_PATH or make a symlik of the library from the above path to /usr/lib64/.
I got this issue because I installed earlier additionally openblas-lapack from AUR for better octave matrix multiplication performance. Updating openblas-lapack to newest version in AUR did the trick for me.
So I downloaded the latest Cuda (5.0.35) script to install Cuda on my desktop on which I have Debian (kernel 2.6.32).
When I ran the script though I get an error on the log which says:
The compiler used to compile the kernel (gcc-4.3) does not exactly match the current compiler (gcc-4.7)
So I looked to install gcc-4.3 from the repositories but it isn't there. Then I downloaded the gcc-4.3 package separately but when I try to install it I get many conflicting dependencies so installing it is really not an option. I installed gcc-4.4 which is in the repositories and changed the soft link for gcc to link to the gcc-4.4 version but I get the same message above
The compiler used to compile the kernel (gcc-4.3) does not exactly match the current compiler (gcc-4.4)
So the question is, is there a way that I can install the driver successfully without relying on the gcc-4.3?
I installed a 3.2 kernel which was compiled with gcc-4.6 and that worked for me. You could also compile the old kernel using gcc-4.7 although I tried it and had some errors. The problem is that Debian uses a very old kernel so it was compiled with gcc-4.3.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.