I want to install gcc 4.2.4 on a linux x86_64, intel cpu with 2 cores, in a not default path.
I downloaded the code via svn and configured from a build directory with
../gcc_424/configure --prefix=/scratch/user/local/gcc-424 --with-local-prefix=/scratch/user/local/include
then in the build directory
make
when I run
make install
I get the error
/bin/sh: line 3: cd: ./fixincludes: No such file or directory
I am a little bit lost with what I should do now, any help?
Although untested (because it's fairly old), EasyBuild should be able to build GCC 4.2 without much trouble.
Just use one of the available example easyconfigs for GCC (the non ClooG-PPL ones), adjust the version number, and run the EasyBuild install command specifying that easyconfig file.
No root priveleges required, and EasyBuild takes care of all the nasty stuff.
Related
I have a project been working on for my research for over a year, Oneapi have been integrated for way longer than 6months, everything working and all. Yesterday I updated some test code, and ran the tests, nothing out of normal. Today I restarted my machine (Ubuntu 20.04.2 LTS, 64bits) for updates, and now when I try to compile the project it gives:
In file included from /opt/intel/oneapi/tbb/2021.2.0/env/../include/oneapi/tbb/enumerable_thread_specific.h:26,
from /opt/intel/oneapi/tbb/2021.2.0/env/../include/oneapi/tbb/combinable.h:22,
from /opt/intel/oneapi/tbb/2021.2.0/env/../include/oneapi/tbb.h:35,
from ...file name omitted for privacy...
/opt/intel/oneapi/tbb/2021.2.0/env/../include/oneapi/tbb/concurrent_vector.h:33:10: fatal error: compare: No such file or directory
33 | #include <compare>
| ^~~~~~~~~
compilation terminated.
This only happened after system restart (possibly broke some links?) and only happens in files that require concurrent_vector.h
Ideally I'd prefer a fix that won't require reinstall of oneapi, apt-get update followed by apt-get upgrade didn't fix it, neither did restarting the system again.
Just ran into the same thing. It looks as if TBB automatically includes <compare> if you are compiling with -std=c++20:
https://github.com/oneapi-src/oneTBB/blob/9e15720bc7744f85dff611d34d65e9099e077da4/include/oneapi/tbb/detail/_config.h#L253
#define __TBB_CPP20_COMPARISONS_PRESENT __TBB_CPP20_PRESENT
GCC only added the compare header in libstdc++-10.
To me, this looks like a bug in TBB. I opened an issue here.
As a hotfix, I was able to downgrade my project to C++17. If that is not an option, you could consider copying detail/_config.h, defining __TBB_CPP20_COMPARISONS_PRESENT 0 in your copy and including it before you include any TBB header. The include guards should make sure that your version supersedes the broken TBB version.
I have an out-of-tree Linux kernel module that I need to compile. When I execute "make" in the kernel module directory I am getting:
"fatal error: stdarg.h: No such file or directory"
Before starting the build I installed the header file based on my Linux distribution.
$sudo apt-get install kernel-headers-$(uname -r)
How can I solve this compilation error? (my distribution is Ubuntu 16.04 with linux-headers-4.15.0-42-generic)
I ran a search of stdarg.h with the "locate" command to see if I can sport the file on the system.
I got:
/usr/include/c++/5/tr1/stdarg.h
/usr/lib/gcc/i686-linux-gnu/5/include/cross-stdarg.h
/usr/lib/gcc/i686-linux-gnu/5/include/stdarg.h
...
It tells me there is at least one stdarg.h provided by the compiler.
I tried to include the path "/usr/lib/gcc/i686-linux-gnu/5/include" in the kernel module Makefile so stdarg.h can be picked up. It did not work (while building, another reference to stdarg.h in the official kernel header was not being resolved).
I finally created a symlink directly under:
/usr/src/linux-headers-4.15.0-42-generic/include
$sudo ln -s /usr/lib/gcc/i686-linux-gnu/5/include/stdarg.h stdarg.h
This was just enough to solve the compilation issue.
I am wondering if the kernel headers should come with an implementation of stdarg.h by default (that is the first time I encounter this issue). I have also read that the compiler provide one implementation and most of the time it is better to use the compiler version.
Updated note: if the above solution still does not solve the problem:
Before running make again, do a make clean. Do a ls -la in the folder and look for a ".cache.mk" file. If this is still there, remove it and run "make" again. It should solve the problem.
I had the same issue with CentOS 9, and the other answers didn't work for me. Apparently the problem is that in more recent kernels, it shouldn't be <stdarg.h> but <linux/stdarg.h>. With virtualbox guest additions 6.1.34, it correctly checks for kernel with a version of 5.15.0 or more. But my kernel is the 5.14.xx, meaning the include for stdarg.h is wrong.
Solving the issue
Dependencies
Install all the dependencies for the guest edition
gcc make perl kernel-devel kernel-headers bzip2 dkms
Installation
Run the Guest Addition installation like you would normally. It will fail by saying it is unable to compile the kernel modules. That's expected. It will copy all the file we need to the VM disk.
Editing
We now need to edit the erroneous files.
/opt/VBoxGuestAdditions-6.1.34/src/vboxguest-6.1.34/vboxguest/include/iprt/stdarg.h
/opt/VBoxGuestAdditions-6.1.34/src/vboxguest-6.1.34/vboxsf/include/iprt/stdarg.h
On line 48 (may change for different versions), it check for a version of Linux and select the correct header depending on the version. We need to replace if RTLNX_VER_MIN(5,15,0) with if RTLNX_VER_MIN(5,14,0) in both files.
Compile the kernel modules
We can now compile the kernel modules, and the error should be gone.
sudo rcvboxadd quicksetup all
I personally got an error the first time, but then I recompiled without changing anything and it worked.
Remember that it's just a workaround, it may not work with different versions.
If you using Arch Linux with zen-kernel:
sudo CPATH=/usr/src/linux-zen/include/linux vmware-modconfig --console --install-all
I had the same problem with VirtualBox 6.1.0 running archlinux with kernel 6.1.9.
I downloaded VirtualBoxGuestAdditions_7.2.0.iso file from https://download.virtualbox.org/virtualbox/7.0.2/ link(you may select more appropriate to your VirtualBox version) and assigned as an optical drive to virtualbox machine. After start of the system running blkid command on terminal showed the name of CD rom device which was /dev/sr0. then I created iso folder on
/mnt folder
mkdir /mnt/iso
and mounted cd drive to that folder
mount -o loop /dev/sr0 /mnt/iso
after I cd'ed to /mnt/iso
cd /mnt/iso
and manually run VirtualBoxGuestAdditions.run script
sh ./VirtualBoxGuestAdditions.run
which successfully compiled and istalled required virtualbox guest modules.
Now everytime I update kernel version I redo the same procedure. And it work fine.
It also remove old 6.1.0 guest additons folder.
I want to install the latest gcc49 in a Ubuntu Linux, and I am familiar with Homebrew in Mac, so I would like to use the Linux version of it, i.e., Linuxbrew. So I installed Linuxbrew and typed
$ brew install gcc49
The dependencies gmp4, mpfr2 and etc. will be installed first. I have added a if OS.mac? condition in gmp4 so it can be installed successfully, but when installing mpfr2 (also added the condition), the make check failed with the error:
...
/tmp/mpfr2-i5YD/mpfr-2.4.2/tests/.libs/lt-tpow_all: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
FAIL: tpow_all
=======================
148 of 148 tests failed
=======================
As you can see, the tests can not find libgmp.so.3 which is just installed. But gmp4 is keg only since it will conflict with gmp in main repository.
But the configure options are set with the correct location of gmp4:
./configure --disable-dependency-tracking --prefix=/home/dongli/.linuxbrew/Cellar/mpfr2/2.4.2 --with-gmp=/home/dongli/.linuxbrew/opt/gmp4
How to solve this problem? Thanks!
You think you are doing it wrong by insisting on a third-party scripting solution that is not native to the OS.
There are prebuilt versions of gcc et al provided by the same maintainers in this PPA on Launchpad. These are previews / testreleases of what will be in the next Ubuntu releases.
I found the problem, that is the environment has been reset after each system call in Ruby formula. So we need to set the correct LD_LIBRARY_PATH as
if OS.linux?
ENV["LD_LIBRARY_PATH"] = "#{Formula["..."].opt_prefix}/lib:...:$LD_LIBRARY_PATH"
end
so that LD_LIBRARY_PATH persists during the build processes.
I am trying to install mpich-3.1 in a linux cluster (Ubuntu 12.04 running on all machines). Previously I installed mpich2 by sudo apt-get install mpich2 but couldn't find how to run tests. Then I removed with sudo apt-get remove mpich2.
So I decided to upgrade to 3.1. I downloaded and installed mpich following instructions at https://www.mpich.org/static/downloads/3.1/mpich-3.1-installguide.pdf by running:
sudo ./configure -prefix=/usr/local/mpich/
sudo make
sudo make install
and apparently is properly installed. If I run
meteo#ventus:~/RAMS/RUN$ /usr/local/mpich/bin/mpiexec -f machinefile -n 20 hostname
ventus
ventus
ventus
ventus
ventus4
ventus4
ventus4
ventus4
ventus5
ventus5
ventus5
ventus5
ventus2
ventus2
ventus2
ventus2
ventus3
ventus3
ventus3
ventus3
Although I find it is responding "slowly". Where machinefile is
ventus:4
ventus2:4
ventus3:4
ventus4:4
ventus5:4
The directory is exported to all nodes in the cluster, /etc/exports
/usr/local/mpich 192.168.1.0/24(rw,sync)
In /etc/mtab ant /etc/fstab in node ventus4
ventus:/usr/local/mpich /usr/local/mpich nfs rw,vers=4,addr=192.168.1.1,clientaddr=192.168.1.4 0 0
ventus:/usr/local/mpich /usr/local/mpich nfs
Maybe the problem comes from a prior install not completely removed
meteo#ventus:~$ which mpiexec
/usr/local/bin/mpiexec
meteo#ventus:~$ which mpirun
/usr/local/bin/mpirun
meteo#ventus:~$ which mpicc
/usr/local/bin/mpicc
Following installation instructions which mpiexec should point to mpich installation bin directory /usr/local/mpich/bin/mpiexec
But if I move /usr/local/bin/mpiexec to /usr/local/bin/mpiexec.old
then
meteo#ventus:~$ which mpiexec
/usr/local/mpich/bin/mpiexec
points to my new mpich3 install directory. Could this be the reason of that slow performance? Which test should I run for benchmarking? How do I completely remove mpich2.
If you do in fact have root access to your entire machine, then you can always just delete all of the binaries, libraries, headers, etc. I'm not sure where everything is installed on your system (it's different everywhere), but the usual locations are /usr/local/bin, /usr/local/include, /usr/local/lib, etc. You should look for these files (or things that look similar:
bin/:
Anything that starts with mpi
include/:
Anything that starts with mpi
Anything that starts with opa
lib/:
Anything that includes mpich
Anything that includes mpl
Anything that includes opa
Beyond that, there's not much that would interfere (there's man pages somewhere too, but that's fine). If you delete all of those files, you should have gotten rid of your MPICH2 installation. This really should have been cleaned up with you did your apt-get uninstall, but that's neither here nor there...
Now, to test your new MPICH installation (the project is called MPICH now, not MPICH3), there are lots of MPI benchmarks. I'd suggest typing mpi benchmarks into your favorite search engine any trying out a few of the ones that you find. If you want to compare, you can install a few different versions of MPI. When you do this, make sure you are correctly setting up your PATH and LD_LIBRARY_PATH environment variables so your installations can sit side by side.
I am trying to install Code::Blocks 10.05 from (non-SVN) sources (codeblocks-10.05-src.tar.bz2). My OS is Ubuntu 11.04. I needed to download and install wxWidgets first (I now have wxGTK-2.8.12), which seemed to work. I compiled it according to these instructions:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux
Then I configured C::B with
./configure --with-wx-config=/opt/wx/2.8/bin/wx-config
and ran
export LDFLAGS="-Wl,-R /opt/wx/2.8/lib"
make
sudo -i
make install
When trying to run C::B, I get the following error:
codeblocks: error while loading shared libraries: libwx_gtk2u-2.8.so.0: cannot open shared object file: No such file or directory
The same question was asked here: error while loading shared libraries, but the suggested solution (namely adding the wxWidgets config to the options passed to configure) didn't work for me.
The output of wx-config --prefix is /opt/wx/2.8,
The output of wx-config --libs is -L/opt/wx/2.8/lib -pthread -lwx_gtk2u-2.8,
and that of which wx-config is /opt/wx/2.8/bin/wx-config.
I looked for the library and found /opt/wx/lib/libwx_gtk2u-2.8.so.0 to be a link to libwx_gtk2u-2.8.so.0.8.0 in the same folder.
What might be wrong here?
The problem is that the program cannot find the WX widgets libraries at run time. You will need to set your LD_LIBRARY_PATH variable to include the location of wxWidgets like this:
LD_LIBRARY_PATH=/opt/wx/2.8/lib ./codeblocks
The reason why its failing is because you compiled codeblocks against wxWidgets found in /opt/ and not the one installed in /usr/; the program doesn't know to look in /opt for the wx libraries.
Probably the easiest way to get code::blocks up and running on Ubuntu is to just install it via the Synaptic Package Manager. Just type in codeblocks into 'Quick search'. Find codeblocks on the list and just right-click to mark for install. Any dependencies and missing libraries needed will automatically be handled and installed by Synaptic as necessary.
If you're interested in trying the C::B nightly builds on Ubuntu then you'll want to checkout Jens' unofficial debian-repository here.
You can visit Why do I have to define LD_LIBRARY_PATH with an export every time I run my application? for a more generic case. For a particular case like yours you can follow the below given steps
If you had installed wxGTK then you would see the file in /usr/local/lib. You would get this error when the the above path is not as part of the makefile. I received this error while starting wxFormBuilder after building from source on CentOS. There are 2 approaches.
Approach 1: Putting the path in .bashrc
gedit /home/{your-username}/.bashrc
Then after the line # User specific aliases and functions paste the following
export $LD_LIBRARY_PATH=/usr/local/lib.
This would work for fine but for the current login, but for other users like root you might have to do the same in the respective .bashrc files.
Approach 2: Creating your own conf files
cd /etc/ld.so.conf.d
gedit wxformbuilder.conf
Give the path /usr/local/lib and save the file.
ldconfig (To update the library path).