I tried to install gfortran 10 from Fedora 31.
Follow https://fortran-lang.org/learn/os_setup/install_gfortran
sudo dnf install gcc-gfortran leads to gfortran 9
I tried to download from https://fedora.pkgs.org/33/fedora-x86_64/gcc-gfortran-10.2.1-3.fc33.x86_64.rpm.html
the download link file leads to Failed to install file, not supported from graphic interface :(
or bash: ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm: cannot execute binary file: Exec format error from terminal with root.
Is there any way to install gfortran-10 from Fedora?
Thanks!
You can of course always compile GCC from source, it is not that hard and the script for getting the prerequisites is included (./contrib/download_prerequisites).
The easiest way is to download one of the snapshots https://gcc.gnu.org/snapshots.html and follow the instructions. You do not even have to have admin rights, you can do it privately in your home directory.
Check whether there is a repository with additional GCC versions for your distro. For example, on my OpenSuSE, I have packages for GCC 7, 8, 9, 10 and 11. And they can be installed concurrently.
Regarding:
bash: ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm: cannot execute binary file: Exec format error
You cannot run a rpm file in bash, you have to install it using rpm -i or using your higher level package manager.
The file you downloaded is an RPM package, not an executable. You would normally install it with dnf install ./gcc-gfortran-10.2.1-9.fc33.x86_64.rpm from the command line. However, that package is for Fedora Linux 33, and you're running 31. Occasionally this works, but generally installing packages from new releases on older releases isn't supported.
If, for some reason you can't upgrade to Fedora Linux 33 for your whole system, one approach is to use the toolbox utility to make a containerized workspace using a F33 container image. Then, you can install the version of gfortran you want into that (with dnf install gcc-gfortran).
You could also use F34 (out tomorrow) but note that that has gcc 11.
Related
I managed to compile QEMU (3.0.50) under Windows 10 (64-bit) (basically following these instructions) with these commands:
./configure --enable-gtk --enable-sdl
make
However, when starting qemu-system-x86_64.exe in a console, nothing happens. I expected a window showing up. Shortly after starting the exe, I'm getting back the prompt. Nothing printed out to the console. No necessary DLL is missing. What could be the problem?
Finally I managed to compile and run QEMU under Windows 10 Home 64-bit.
There are a few pitfalls:
Due to a compiler bug in mingw (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 and https://www.mail-archive.com/qemu-devel#nongnu.org/msg557409.html), you have to configure QEMU with --disable-stack-protector and (one solution) add the function __stack_chk_fail to a source file.
Configure QEMU with --disable-werror.
Remove Capstone project from makefile.
Here's a complete step-by-step guide for compiling qemu-system-x86_64.exe:
Date: 2018-10-31
OS: Microsoft Windows 10 Home 64-bit
Guide based on: https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2
Download and install msys2 to C:\msys64:
http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20180531.exe
Start C:\msys64\mingw64.exe
Updates (then close window and restart mingw64.exe): pacman -Syu
Updates: pacman -Su
Install basic packets: pacman -S base-devel mingw-w64-x86_64-toolchain git python
Install QEMU specific packets: pacman -S mingw-w64-x86_64-glib2 mingw-w64-x86_64-gtk3 mingw-w64-x86_64-SDL2
Get QEMU sources:
git clone git://git.qemu-project.org/qemu.git
cd qemu
git submodule update --init ui/keycodemapdb
git submodule update --init capstone
git submodule update --init dtc
Insert
void __stack_chk_fail(void);
void __stack_chk_fail(void)
{
}
to qemu\util\oslib-win32.c
e.g. at line 44
Comment out (#) Capstone (line 508) in qemu\Makefile
Build QEMU:
./configure --enable-gtk --enable-sdl --target-list=x86_64-softmmu --disable-werror --disable-stack-protector
make
Run in qemu/x86_64-softmmu
./qemu-system-x86_64 -L ./../pc-bios
Optional (for better performance): Install HAXM according to this guide: https://www.qemu.org/2017/11/22/haxm-usage-windows/ and start QEMU with option -accel hax
I would do know if somebody tried in 2022 i have currently some issues after compiling.
Firt it asks for libzstd.dll, when i go to the project i found by google and dl this dll, i encounter another issue
with x64.dll
with x32.dll (just in case)
i use msys2 minGw x64 on windows 10 pro x64. At the beginning i would compile a patch, but it the same problem with vanilla, i ask myself if it's an environment problem, a missing dll, or if it's always possible to compile directly on windows10, perhaps now it's only possible to compile in cross platform. I'm not habit at all with mingw64 tools.
I looked for the g_spanw... error and found this https://docs.gtk.org/glib/func.spawn_async_with_fds.html
Perhaps i'm wrong but it's only for gnome, isn't it ?
I am attempting to install closed source software from Silego, GreenPAK Designer, on a machine running Fedora 19. The supported installation packages on Silego's Website only target Ubuntu and Debian. I downloaded the .deb package and used Alien to convert to an RPM. So far so good, but a dry run of yum install showed dependency errors, which I solved by installing the necessary packages with yum:
qt5-qbase
qt5-qbase-gui
qt5-qtdeclarative
qt5-qtlocation
qwt
Now, yum installed the above libraries in /usr/lib/ but the GreenPAK RPM defaults to /usr/local/bin as the output dir. I figured I could run
sudo yum localinstall --nodeps --noscripts greenpak-designer-x.x.x.rpm
and get a successful install but I received conflict errors relating to dirs such as '/', '/usr', '/usr/bin' etc. I worked around this issue with:
rpmrebuild -pe --notest-install --replacefiles --noscripts greenpak-designer.x.x.x.rpm
and removing the offending lines in the script. It allowed me to install rpm but the software is broken because of dependency issues (not surprisingly). From the system log:
Jan 4 16:06:49 pelican gnome-session[1729]: /usr/local/greenpak-designer/bin/GP5: error while loading shared libraries: libicui18n.so.52: cannot open shared object file: No such file or directory
The machine has a /usr/lib/libicui18n.so.50
One thing I did not try is rebuilding my shared object cache with ldconfig, which sometimes solves problems with missing .so links when building from source but I don't see how that would apply in this instance (I'm not trying to link object files to libraries, rather simply trying to drop binaries in default install locations, no?)
Of course, I contacted the vendor and begged for an RPM. The contact was helpful but informed me the software folks are on a well deserved break. I thought I'd continue puttering with this in the meantime while I have time.
Any ideas? It seems the solution to this problem would be helpful when trying to install almost any closed source software targeting Debian on a Fedora box.
Install information:
Using DBI 1.608 (for perl 5.008009 on x86_64-linux) installed in /usr/local/lib/perl5/site_perl/5.8.9/x86_64-linux/auto/DBI/
error information:
[root#datacenterETL DBD-mysql-4.020]# perl ../testConnect.pl
install_driver(mysql) failed: Can't locate DBD/mysql.pm in #INC (#INC contains: /usr/local/lib/perl5/5.8.9/x86_64-linux /usr/local/lib/perl5/5.8.9 /usr/local/lib/perl5/site_perl/5.8.9/x86_64-linux /usr/local/lib/perl5/site_perl/5.8.9 .) at (eval 3) line 3.
Perhaps the DBD::mysql Perl module hasn't been fully installed, or perhaps the capitalisation of 'mysql' isn't right.
It looks like you're using Linux. In that case, you might find it easier to install a pre-packaged version of the module.
On a Red Hat derivative try yum install perl-DBD-mysql; on a Debian derivative try apt-get install libdbd-mysql-perl.
Perhaps the DBD::mysql perl module hasn't been fully installed
...so install it.
cpan DBD::mysql
Or since you don't have internet access,
perl Makefile.PL
make
make test
make install
You'll need MySQL's development header files installed first, as per INSTALL
any error related to DBD::mysql error has not installed fully. Please run the below code in super user permission.
apt-get install libdbd-mysql-perl
As is was not able to comment (yet), I want to add something for the Mac Users.
I hat to add the --force command to install the everything properly as i have no local mySQL installation for the tests to pass.
/usr/bin/cpanm --force DBD::mysql worked for me. (Mac OS 10.9.2, Perl 5.12.4)
I've been tried perl -MCPAN -e shell on my mac OSX 10.8.5, but this didn't work.
I tried sudo perl -MCPAN ..., but didn't work too. I changed my ~.bash_profile to include
LD_RUN_PATH=/usr/local/mysql-5.6.13-osx10.7-x86_64/lib export LD_RUN_PATH
LD_LIBRARY_PATH=/usr/local/mysql-5.6.13-osx10.7-x86_64/lib export LD_LIBRARY_PATH
lines, and I tried -MCPAN again, with and without sudo, but this didn't work too.
I read some posts and I tried "get Bundle::DBD::mysql" in -MCPAN command line to download it and install with Makefile. Then, I entered the ~./cpan/build directory and I did a Makefile, but the make command didn't work. I tried Makefile with --testuser and --testpassword that I just had been configure in mysql. I entered the site https://discussions.apple.com/thread/3932531?start=0&tstart=0&fb_source=message that is informed in README doc of ./cpan/bundle, but I already had all command line tools of xCode installed and didn't work for me too.
Why don't do sudo perl -MCPAN -e shell and to force to install Bundle::DBD::mysql? This worked well and I got the installation.
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
So where do I go from here? I'm guessing that there is a bugfix somewhere in libXss. libXss tries to install i686 arch for all it's dependencies.
I'm using Fedora 24 x86_64
Terminal Output
sudo rpm -ivh atom.x86_64.rpm
error: Failed dependencies:
libXss.so.1 is needed by atom-1.13.0-0.1.x86_64
sudo dnf install libXss.so.1
Error: Transaction check error:
file /usr/share/doc/glibc/NEWS from install of glibc-2.23.1-11.fc24.i686 conflicts with file from package glibc-2.23.1-7.fc24.x86_64
sudo dnf install glibc-2.23.1-11.fc.24.x86_64
Package glibc-2.23.1-11.fc24.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
Secondary/Unimportant Question
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
edit
I gave up and decided to install from the copr repo
sudo dnf copr enable mosquito/atom
sudo dnf install atom
Error: Transaction check error:
file /usr/lib64/libkadm5clnt_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
file /usr/lib64/libkadm5srv_mit.so.10.0 from install of libkadm5-1.14.4-4.fc24.x86_64 conflicts with file from package krb5-libs-1.14.1-6.fc24.x86_64
What is going on?
Can I bypass installing glibc.i686 as a dependency when I already have the x86_64 version?
Not if you need to install 32-bit software — you'll need the 32-bit libs for that. 64-bit libraries aren't supersets of the 32-bit ones.
I'm trying to install Atom from the official RPM provided. libXss.so.1 is a dependency and tries to install the 32-bit version of glibc when I already have the 64-bit version. It then conflicts with the 2.23.1-7 older version of glibc that I already have.
This is a frequent problem. Installing 32-bit versions of packages without updating to the latest versions of the main 64-bit packages is not supported. Upgrade first, then install.
Do I need glibc-2.23.1-7.fc24.x86_64 when I already have glibc-2.23.1-11.fc24.x86_64? I see that I have both installed yet I have no conflict problems.
This can happen if there's an interrupted upgrade transaction. You should be able to dnf remove glibc-2.23.1-7.fc24.x86_64 safely. If that gives you errors, time to stop and make sure nothing else is wrong. Or, you can really just ignore it — next time a new glibc update comes out, it should replace both.
I gave up and decided to install from the copr repo
The errors you see here are actually the same root problem as trying to install 32-bit packages without updating first. RPMs can share files, as long as they are completely identical. That's true in matched versions of the various kerberos packages, but not true if there's a mismatch, and the dependency information doesn't handle this. So, again upgrade to latest packages before installing new ones.
I know that I can install Cuda with the following:
wget http://developer.download.nvidia.com/compute/cuda/7_0/Prod/local_installers/cuda_7.0.28_linux.run
chmod +x cuda_7.0.28_linux.run
./cuda_7.0.28_linux.run -extract=`pwd`/nvidia_installers
cd nvidia_installers
sudo ./NVIDIA-Linux-x86_64-346.46.run
sudo modprobe nvidia
sudo ./cuda-linux64-rel-7.0.28-19326674.run
Just wondering if I can install Cuda without root?
Thanks,
Update The installation UI for 10.1 changed. The following works:
Deselect driver installation (pressing ENTERon it)
Change options -> root install path to a non-sudo directory.
Press A on the line marked with a + to access advanced options. Deselect create symbolic link, and change the toolkit install path.
Now installation should work without root permissions
Thank you very much for the hints in the question! I just want to complete it with an approach that worked for me, also inspired in this gist and that hopefully helps in situations where a valid driver is installed, and installing a more recent CUDA on Linux without root permissions is still needed.
TL;DR: Here are the steps to install CUDA9+CUDNN7 on Debian, and installing a pre-compiled version of TensorFlow1.4 on Python2.7 to test that everything works. Everything without root privileges and via terminal. Should also work for other CUDA, CUDNN, TensorFlow and Python versions on other Linux systems too.
INSTALLATION
Go to NVIDIA's official release web for CUDA (as for Nov. 2017, CUDA9 is out): https://developer.nvidia.com/cuda-downloads.
Under your Linux distro, select the runfile (local)option. Note that the sudo indication present in the installation instructions is deceiving, since it is possible to run this installer without root permissions. On a server, one easy way is to copy the <LINK> of the Download button and, in any location of your home directory, run wget <LINK>. It will download the <INSTALLER> file.
Run chmod +x <INSTALLER> to make it executable, and execute it ./<INSTALLER>.
accept the EULA, say no to driver installation, and enter a <CUDA> location under your home directory to install the toolkit and a <CUDASAMPLES> for the samples.
Not asked here but recommended: Download a compatible CUDNN file from the official web (you need to sign in). In my case, I downloaded the cudnn-9.0-linux-x64-v7.tgz, compatible with CUDA9 into the <CUDNN> folder. Uncompress it: tar -xzvf ....
Optional: compile the samples. cd <CUDASAMPLES> && make. There are some very nice examples there and a very good starting point to write some CUDA scripts of yourself.
(If you did 5.): Copy the required files from <CUDNN> into <CUDA>, and grant reading permission to user (not sure if needed):
cp -P <CUDNN>/cuda/include/cudnn.h <CUDA>/include/
cp -P <CUDNN>/cuda/lib64/libcudnn* <CUDA>/lib64
chmod a+r <CUDA>/include/cudnn.h <CUDA>/lib64/libcudnn*
Add the library to your environment. This is typically done adding this following two lines to your ~/.bashrc file (in this example, the <CUDA> directory was ~/cuda9/:
export PATH=<CUDA>/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<CUDA>/lib64/
FOR QUICK TESTING OR TENSORFLOW USERS
The quickest way to get a TensorFlow compatible with CUDA9 and CUDNN7 (and a very quick way to test this) is to download a precompiled wheel file and install it with pip install <WHEEL>. Most of the versions you need, can be found in mind's repo (thanks a lot guys). A minimal test that confirms that CUDNN is also working involves the use of tf.nn.conv2d:
import tensorflow as tf
x = tf.nn.conv2d(tf.ones([1,1,10,1]), tf.ones([1,5,1,1]), strides=[1, 1, 1, 1], padding='SAME')
with tf.Session() as sess:
sess.run(x) # this should output a tensor of shape (1,1,10,1) with [3,4,5,5,5,5,5,5,4,3]
In my case, the wheel I installed required Intel's MKL library, as explained here. Again, from terminal and without root users, this are the steps I followed to install the library and make TensorFlow find it (reference):
git clone https://github.com/01org/mkl-dnn.git
cd mkl-dnn/scripts && ./prepare_mkl.sh && cd ..
mkdir -p build && cd build
cmake -D CMAKE_INSTALL_PREFIX:PATH=<TARGET_DIR_IN_HOME> ..
make # this takes a while
make doc # do this optionally if you have doxygen
make test # also takes a while
make install # installs into <TARGET_DIR_IN_HOME>
add the following to your ~/.bashrc: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<TARGET_DIR_IN_HOME>/lib
Hope this helps!
Andres
You can install using conda with the following command.
conda install -c anaconda cudatoolkit
But you need to have prior accesss to the device(GPU).
EDIT : If you are finding error in anaconda repository then change the repository to conda-forge which is frequently updated.
conda install -c conda-forge cudatoolkit
You can install CUDA and compile programs, but you won't be able to run them for a lack of device access.