I'm trying to install/compile OpenFOAM on a remote server. As I don't have the admin privileges I have to compile it from scratch. Following the instructions here, when I try to run
source ~/OpenFOAM/OpenFOAM-v1712/etc/bashrc
I get the error:
No completion added for /home/foobar/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/bin
I checked the ~/OpenFOAM/OpenFOAM-v1712/etc/bashrc definitely exists and it is intact. I also checked the /home/foobar/OpenFOAM/OpenFOAM-v1712/ folder and there are no such thing as platforms folder! I searched and the only place I could see a similar error message is here where the issue is old Bash. I tried bash --version returning version 4.3.48(1)-release (x86_64-pc-linux-gnu) which is more than 4.2 as seems to be required.
My system information:
When I run the uname -a command on the server this is what I get
Linux foobar 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Looking into the possible required dependencies mentioned in this page, I checked the installed packages using the command apt list --installed | grep -i packageName, The packages installed are:
build-essential, flex, bison, cmake, zlib1g-dev, libboost-system-dev, libboost-thread-dev, libopenmpi-dev, openmpi-bin, gnuplot, libreadline-dev, libqt4-dev, libqt4-opengl-dev, freeglut3-dev,
And the ones not installed are:
libncurses-dev, libxt-dev, libqtwebkit-dev, libcgal-dev
which according to the installation page are not essential I suppose.
and checking the versions of the libraries installed:
mpirun --version --> (Open MPI) 1.10.2
gcc --version --> gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
cmake --version --> 3.5.1
I would appreciate if could let me know
What is the problem and how I can solve it?
if not solvable, what are the alternative methods for me to have the OpenFOAM installed/compiled on the said server.
This is really embracing as it was just a wrong error! I was informed here that I could have ignored the error and go forward with compiling. Of course I couldn't compile the ParaVIEW/paraFoam as dependencies lack, but it is just a headless server without any GUI. So if you got this error just ignore it and go forwards with the compiling with:
./Allwmake
I have reported the issue here so they can fix it.
P.S. I reported this issue almost 9 month ago and now there is a new confusing message instead of the old one!
No completion added for /home/foobar/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/bin
... incorrect platform, or not yet compiled?
Related
I've recently started working on a project that requires my complier to be above GNAT 4.8.5 - When I go to: Help > About
You can see that the version I'm using is 4.8.5
Also, when I run the gnatls -v command, I can see this...
[parallels#localhost ~]$ gnatls -v
GNATLS 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright (C) 1997-2013, Free Software Foundation, Inc.
Source Search Path:
<Current_Directory>
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/adainclude/
Object Search Path:
<Current_Directory>
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/adalib/
Project Search Path:
<Current_Directory>
/usr/x86_64-redhat-linux/lib/gnat
/usr/share/gpr
/usr/lib/gnat
[parallels#localhost ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=c,c++,ada
Thread model: posix
gcc version 7.3.0 (GCC)
[parallels#localhost ~]$
Please could someone be able to tell me how to update my GNAT compiler? Also, I'm using the Centos 7 Operating System.
Thank you,
Lloyd
You don't need to install a compiler, you already have 3 (at least):
gcc 4.8.5 (the system compiler) in /usr/bin
gcc 7.3.0 (that you just built) in /usr/local/bin
gcc 8.3.1 (from GNAT CE 2019) in /home/parallels/opt/GNAT/2019/bin
Your PATH determines which GCC you pick up when you say just gcc, and which GNATLS you pick up when you say just gnatls, .. etc.
According to a previous post, your PATH is:
$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/parallels/.local/bin:/home/parallels/bin/home/parallels/opt/GNAT/2019/bin/home/parallels/opt/GNAT/2019/bin
so when you say just gcc the system looks at the first entry in the PATH (which is colon-separated) and .. there it is! so it executes that.
If you'd built your 7.3.0 GCC with Ada support, it would have found gnatls in the same place. I have a very strong suspicion that you didn't, so when you say just gnatls the system looks in /usr/local/bin - no luck - then in /usr/local/sbin - no luck - then in /usr/bin - whoopee! but that's the 4.8.5 GCC that you don't want.
Looking again at your PATH, the last part is mangled - you've added /home/parallels/bin and /home/parallels/opt/GNAT/2019/bin (twice) without including the colon separators, resulting in a nonexistent path. (/home/parallels/bin may well have been added by the system - I assume that /home/parallels is your home directory).
What you need to do is to make sure that you pick up the compiler that came with GNAT CE 2019 by putting its location first in your PATH. One way of doing this is by editing your shell startup files.
I don't know how CENTOS sets accounts up, and I don't know what your shell is. Assuming it's bash (type ps -p $$, should come back with bash or perhaps -bash; anything else, I can't help), you need to edit one of the shell startup files - I'm a little unclear about this, but I think it'll be ~/.bashrc (~ is shorthand for your home directory); see here for the gory details. Find the last mention of PATH and immediately after that line insert
export PATH=/home/parallels/opt/GNAT/2019/bin:$PATH
Open a new terminal window and say e.g. gnatls -v - you should pick up the GNAT CE 2019 one.
Only way I know of updating GNAT GPS CE from AdaCore is downloading the new one, installing it and then deleting the old one.
Another thing is to upgrade the gnat-gps that some systems had in ther repositories
I'm trying to install pyAlsaaudio on my openSUSE distro
Output of uname -a: Linux linux-0cd5 4.12.14-lp150.12.48-default #1 SMP Tue Feb 12 14:01:48 UTC 2019 (268f014) x86_64 x86_64 x86_64 GNU/Linux
I downloaded the source from this link,
http://larsimmisch.github.io/pyalsaaudio/pyalsaaudio.html
which includes a py setup file.
Initially I didn't have the gcc compiler installed, so I just installed it.
Snipped output of gcc -v: gcc version 7.3.1 20180323 [gcc-7-branch revision 258812] (SUSE Linux)
The setup.py file is still giving me issues, I think because I am missing the alsa/asoundlib.h file, similar to this thread:
https://ubuntuforums.org/showthread.php?t=1586707
However, the solution there doesn't work for openSUSE, there isn't a libasound2-dev available for openSUSE.
Any ideas?
I just found an answer for this here:
https://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069794.html
I used the following command:
sudo zypper install -C 'pkgconfig(alsa)'
which pointed me to a package I wasn't aware of - "alsa-devel". I wasn't able to find this package when I searched for things like "libasound"
Now I have the proper alsa/asoundlib.h file which is something that the creators of pyalsaaudio note could cause issues if it is absent.
setup.py compiles without issues now! Hope this helps someone else avoid losing 2 hours of googling!
The newest publicly available tcpslice version 1.2a1 (found on its github) has a bug where it expects 8 bytes for a time field but gets 16 (when in 64 bit). This leads to the error:
tcpslice: problems finding end packet of file ./abc1234.bin
I got my info for this error from: https://bugzilla.redhat.com/show_bug.cgi?id=485670
This led me to grab the updated version (1.2a3) from here and try compiling from source: http://pkgs.fedoraproject.org/repo/pkgs/tcpdump/tcpslice-1.2a3.tar.gz/. I think this is or close to the actual patch
HOWEVER, I couldn't ./configure this on my mac because it says (understandably) this:
checking build system type... configure: error: cannot guess build type; you must specify one
Not one to give up, and becuase I don't wnat to switch over to linux to continue deveolping my wrapper script, I tried to compile like this:
./configure --build=i686-pc-linux-gnu
This configured and make'd!!! However, its 32 bit which still gives the same error when I run the newly made tcpdump!!
Is this possible at all, and what other --build type can I use that is for x86_64 bit systems? No other --build types are compiling for me. I have no idea how to find acceptable build types, and am currently referenceing this: https://gcc.gnu.org/gcc-4.2/buildstat.html
EDIT: I tried Warren Young's suggestion here but libtoolize --force did not remake config.guess, so I manually downloaded the "newest" config.guess from the link on this page with curl. However, now ./configure says:
checking build system type... Invalid configuration `x86_64-apple-darwin15.4.0': machine `x86_64-apple' not recognized
configure: error: /bin/sh ./config.sub x86_64-apple-darwin15.4.0 failed
Am I screwed? Or can I sitll try a default x86_64 -build type (which I still cannot find):
checking build system type... Invalid configuration `x86_64': machine `x86_64' not recognized
configure: error: /bin/sh ./config.sub x86_64 failed
Welp, the answer was to manually download the newest config.guess and config.sub files from here: https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html and to overwrite the ones in the tcpslice directory.
However, the same problem still existed. There must be another reason the time issue is happening on the mac because this version of tcpslice worked fine on ubuntu on the same pcap.
Thanks to Warren Young's post in this question for guiding me in the right (though not successful) direction: Compiling tcpsplice on a 64-bit machine. Guess I'll be using ubuntu to finish my script!
I just upgraded from Ubuntu 10 to Ubuntu 14 and now get link errors when I try to build app server that uses OpenSSL. This occurs only on functions related to multithreading support e.g., CRYPTO_num_locks(). These functions still exist in the /usr/include/openssl headers, but seem not to be in the libraries I have. I installed via:
apt-get install libcurl4-openssl-dev
#define OPENSSL_THREAD_DEFINES
#include <openssl/opensslconf.h>
results in OPENSSL_THREADS being defined, which is supposed to mean the libraries support.
The solution was to add -lcrypto to the gcc linker command line. I guess these functions got moved to their own library at some point, or something else was letting the linker find them on Ubuntu 10. I have to thank RedHat for pointing this out. It produced same error as ubuntu gcc, but with additional suggestion to add libcrypto.so to the command line.
When trying to compile glibc on ubuntu 10.10, x86_64, i get the error:
../misc/syslog.c: In function ‘__vsyslog_chk’:
../misc/syslog.c:123: sorry, unimplemented: inlining failed in call to ‘syslog’: function body not available
../misc/syslog.c:155: sorry, unimplemented: called from here
make[2]: *** [/home/daniel/src/b.c/misc/syslog.o] Error 1
Try this wiki about glibc build issues.
I just ran into the same issue but with 32-bit. When running the configure script, adding CFLAGS='-U_FORTIFY_SOURCE -O2' to the command line seems to work. You may need to add -mtune=i686 and -march=i686 in there too. But maybe not for 64 bit. The i686 seems to be another bug.
Whenever you want to rebuild something on Ubuntu that Debian already, you are almost always best of by starting with the original source package on Debian.
In this particular case you can start with this version from the Debian experimental branch. By using the source package, you ensure you have required build-dependencies and should minimize surprises.
Also, building in a chroot environment is a good way to do this and made easy by packages such as pbuilder and sbuild.
Edit: There are build logs but they don't contain one for amd64, presumably because the maintainers built on that locally. But you can look at i386, say, and see that it passed the error you had.