Netcdf-Fortran failure when installing: netcdf-fortran-4.5/nf03_test - netcdf

I am desperated and hope someone might be able to bring some light on this problem:
I am trying to install netcdf-fortran in Fedora 35 using Intel compilers. To do so, I first installed ONEAPI from intel in /opt/intel/oneapi. Then, I install
https://gmplib.org/download/gmp/gmp-6.2.0.tar.lz
https://www.mpfr.org/mpfr-current/mpfr-4.1.0.tar.gz
https://ftp.gnu.org/gnu/mpc/mpc-1.2.1.tar.gz
git clone https://gnu.googlesource.com/gcc
git checkout releases/gcc-10
source /opt/intel/oneapi/setvars.sh intel64
export PATH=/opt/intel/oneapi/compiler/2021.4.0/linux/bin:$PATH
export LD_LIBRARY_PATH=/opt/intel/oneapi/compiler/2021.4.0/linu/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/opt/intel/oneapi/compiler/2021.4.0/lib/pkgconfig:$PKG_CONFIG_PATH
export C_INCLUDE_PATH=/opt/intel/oneapi/compiler/2021.4.0/linux/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/opt/intel/oneapi/compiler/2021.4.0/linux/include:$CPLUS_INCLUDE_PATH
Then exported the utilities directory where I am install all these packages and exported it accordingly.
Then, I kept installing:
szip-2.1.1.tar
libjpeg-turbo-2.1.2
gzip-1.11
bzip2-1.0.8
libuuid-1.0.3
brotli
gperf-3.1
gettext-0.21
hdf-4.2.15
hdf5-1.13.0
netcdf-c-4.8.1
and up everything compiles and works fine. Yet, when I tried to install
https://downloads.unidata.ucar.edu/netcdf-fortran/4.5.3/netcdf-fortran-4.5.3.tar.gz
Then it keeps failing and failing with the error:
make[3]: * [Makefile:728: test-suite.log] Error 1
make[2]: * [Makefile:836: check-TESTS] Error 2
make[2]: Leaving directory '/SOME/LOCAL/ADDRESS/netcdf-fortran-4.5.0/nf03_test'
make[1]: * [Makefile:917: check-am] Error 2
make[1]: Leaving directory '/SOME/LOCAL/ADDRESS/netcdf-fortran-4.5.0/nf03_test'
I don't know what the problem is but it is not a problem with the version as even if I install an older version, the error keeps being the same.
I tried to follow the instructions I was finding about how to install these libraries.
Can someone please give me an advice on how to do this?
My configure is as follows:
CC=icc FC=ifort F77=ifort CPP="icc -E" ./configure --prefix=$PRFX --with-sysroot=$PRFX --with-pic
I have defined:
PRFX=/SOME/LOCAL/ADDRESS/
Thank you in advance,

When you say "... and up everything compiles and works fine." did you mean that you compiled all those packages with ONEAPI? or did you just install those from the depository?
It is much predictable to install netcdf-f when all other dependencies are compiled with a same compiler. Or you should refer to cross-compilation for all required dependencies.
Did you compile hdf5 and netcdf-c (which are one of the basic dependencies for netcdf-fortran) with the ONEAPI? If not, I recommend you doing that first.
I realized that using different compiler than GCC when compiling netcdf-fortran generates an error regarding shared library. You should try compiling it with static library by adding "--disable-shared --enable-static" during the "configuration" stage (for detailed instructions, consult the "Building with static libraries" sections of this link). Make sure you explicitly link the 'include' and 'lib'
directories when you are using the netcdf-f library.

Related

homebrew not installing JAGS

I'm trying to install JAGS through homebrew so I can use it in R. I am getting the following warning every time I install:
Warning: jags dependency gcc was built with a different C++ standard
library (libstdc++ from clang). This may cause problems at runtime.
Then, when I try to install rjags in R, I get the following error:
configure: error: "cannot link to JAGS library in /usr/local/Cellar/jags/4.3.0_2/lib."
ERROR: configuration failed for package ‘rjags’
* removing ‘/usr/local/lib/R/4.0/site-library/rjags’
I also tried following the installation guide in the JAGS 4.3.0 readme. This yielded the same error once I moved to R.
Googling leads me to the following links, none of which seem closely related enough to help me:
https://github.com/Homebrew/brew/issues/4904
https://github.com/Homebrew/homebrew-core/issues/32112
Link different C++ standard libraries on Mac OS X
Here also is the entire result of my brew doctor
(base) aridf#Aris-MacBook-Pro ~ % brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
/Users/aridf/opt/anaconda3/bin/icu-config
/Users/aridf/opt/anaconda3/bin/krb5-config
/Users/aridf/opt/anaconda3/bin/freetype-config
/Users/aridf/opt/anaconda3/bin/xslt-config
/Users/aridf/opt/anaconda3/bin/libpng16-config
/Users/aridf/opt/anaconda3/bin/libpng-config
/Users/aridf/opt/anaconda3/bin/xml2-config
/Users/aridf/opt/anaconda3/bin/python3-config
/Users/aridf/opt/anaconda3/bin/curl-config
/Users/aridf/opt/anaconda3/bin/ncursesw6-config
/Users/aridf/opt/anaconda3/bin/pcre-config
/Users/aridf/opt/anaconda3/bin/python3.8-config
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libtcl8.6.dylib
/usr/local/lib/libtk8.6.dylib
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/fakemysql.h
/usr/local/include/fakepq.h
/usr/local/include/fakesql.h
/usr/local/include/itcl.h
/usr/local/include/itcl2TclOO.h
/usr/local/include/itclDecls.h
/usr/local/include/itclInt.h
/usr/local/include/itclIntDecls.h
/usr/local/include/itclMigrate2TclCore.h
/usr/local/include/itclTclIntStubsFcn.h
/usr/local/include/mysqlStubs.h
/usr/local/include/odbcStubs.h
/usr/local/include/pqStubs.h
/usr/local/include/tcl.h
/usr/local/include/tclDecls.h
/usr/local/include/tclOO.h
/usr/local/include/tclOODecls.h
/usr/local/include/tclPlatDecls.h
/usr/local/include/tclThread.h
/usr/local/include/tclTomMath.h
/usr/local/include/tclTomMathDecls.h
/usr/local/include/tdbc.h
/usr/local/include/tdbcDecls.h
/usr/local/include/tdbcInt.h
/usr/local/include/tk.h
/usr/local/include/tkDecls.h
/usr/local/include/tkPlatDecls.h
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
Thanks!
The solution, per https://gist.github.com/casallas/8411082, was to change ~/.R/Makedir to the following:
CC=clang
CXX=clang++
Then reinstall the package in R

How do I compile bitcoin core to be more portable?

Background: I compile bitcoind on one system but run it on another. When I compiled bitcoind 0.19.1 some time back using the following method, I was able to run bitcoind and bitcoin-cli on the target system without issue. I think.
./autogen.sh
./configure --disable-wallet --disable-tests --disable-bench --disable-gui --enable-util-tx=no --prefix=$HOME/bitcoind/x64 --exec-prefix=$HOME/bitcoind/x64
make && make install
Today I compiled v0.20.0 using the same method. If I run ./bitcoind -version on the system I compiled the binary it runs fine, but if I take the binary to my target system I get the following error:
./bitcoind: error while loading shared libraries: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
The binary seemed to be portable last time, and the pre-compiled binary I download from the Bitcoin Core team runs fine.
Note that on the target system libboost-filesystem-dev and libboost-filesystem1.67-dev are not installed, this is likely the source of my error. That said, running the pre-compiled binary from the Core team runs, so why doesn't mine?
Can someone help me understand if I did something wrong or if I need to add ./configure flags to make the binary more portable? Specifically what I likely did differently than the core developers that made my binary fail where theirs worked?
EDIT 1: Running ./configure --enable-static or ./configure LDFLAGS=-static does not result in a portable binary either.
Also note that installing libboost-filesystem library with apt does fix the error.
Thanks to Andrew Chow for his helpful answer to this on the bitcoind StackExchange. I needed to build the depends as per the depends documentation. Since I'm building for the same platform I'll be running on, I can run make in the depends directory with no arguments except -j2 which uses two cores. Change the number to however many cores you want to commit to the compile.
cd depends
make -j2
cd ..
./autogen.sh
./configure --prefix=$PWD/depends/x86_64-pc-linux-gnu
make -j2 && make install

Unable to compile AdaControl: unknown project file: "asis"

I downloaded the source for AdaControl from the SourceForge Repo. Using GNAT 2017 CE, I get the following error on make:
$ make build
gprbuild build.gpr adactl -cargs -bargs -largs
build.gpr:1:06: unknown project file: "asis"
gprbuild: "build.gpr" processing failed
make: *** [adactl] Error 4
The instructions make it sound like this is all I need to do, and offer no troubleshooting suggestions:
Go to the root directory of the distribution and type:
make build make install
As this related question notes, I have managed to get ASIS to build, though it also comes packaged with GNAT 2017 CE.
That message means that ASIS4GNAT isn't installed in a place where gprbuild (and the rest of your GCC/Ada tool-chain) can find it.
You can use the command gnatls -v to get an idea about where your GCC/Ada tool-chain expects project files to be located.
Compare that to where you actually installed ASIS4GNAT, and you may be closer to a solution.

Adding module to existing Qt5 installation from source

I have an existing Qt5.3.2 installation from tar.gz source files.
When attempting to compile VTK, which has optional Qt{4,5} interface, I was informed I don't have QtWebKitWidgets by ccmake.
I don't particularly want to reinstall Qt5 on top of the existing installation, for fear of breaking other things built against it.
Can I add to my current Qt5?
Would variants on
/path/to/configure -release -prefix $existingPrefix
make -module-qtwebkit
make install
or
/path/to/configure -release -prefix $newPrefix
make -module-qtwebkit
make install
cp -rf $newPrefix/CMake/QtWebKit (or similar path) $existingPrefix/CMake/
or as above, but with symlink, work?
Qt5.3 no longer includes QtWebKit, which should now be built separately.
The WebKit package can be downloaded from the Qt Downloads website, via the separate packages repository: link for 5.3.2
This can then be installed by appropriately setting environment variables such that the relevant (Qt5.3.2) qmake is first in the path, then from the expanded source directory, typing:
qmake
make -jN (with N make jobs)
(sudo, if appropriate) make install
The download is approximately 50MB.
Edit: It's also worth noting that if your Bison version is 3.x, then you might not be able to build the snapshot for QtWebKit. Instead download from the development repositories, to avoid an error looking something like: link to bug report
g++ -c [...] -o .obj/release-shared/generated/glslang_tab.o generated/glslang_tab.cpp
generated/glslang_tab.cpp: In function 'int yyparse(TParseContext*)':
generated/glslang_tab.cpp:1785:30: error: too few arguments to function 'int yylex(YYSTYPE*, void*)'
yychar = yylex (&yylval);
^
generated/glslang_tab.cpp:279:12: note: declared here
extern int yylex(YYSTYPE* yylval_param, void* yyscanner);

An error building Qt libraries for the raspberry pi

I am trying to compile the Qt 5 libraries for my RPI, but it always crashes.
These are the guides I have tried to follow:
http://qt-project.org/wiki/RaspberryPi_Beginners_guide
http://qt-project.org/wiki/RaspberryPi
I have downloaded the cross-compiler and sysroot-image according to the guide and pulled the Qt5 sources from the git repo.
After following one of the guides I am now stuck at make.
This is the error I am receiving:
.obj/release-shared/qlibrary_unix.o: In function `QLibraryPrivate::load_sys()':
qlibrary_unix.cpp:(.text+0xf84): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlopen.o): In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlclose.o): In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlsym.o): In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlerror.o): In function `dlerror':
(.text+0x0): undefined reference to `__dlerror'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libm.a(feholdexcpt.o): In function `feholdexcept':
(.text+0x48): undefined reference to `_dl_hwcap'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libm.a(fesetenv.o): In function `fesetenv':
(.text+0x64): undefined reference to `_dl_hwcap'
collect2: virhe: ld:n paluuarvo oli 1 # collect2: error: ld returnvalue was 1
make[2]: *** [../../lib/libQt5Core.so.5.0.0] Virhe 1 # Error 1
make[2]: Poistutaan hakemistosta "/home/esa/qtonpi/qt5/qtbase/src/corelib" # Leaving directory
make[1]: *** [sub-corelib-make_first] Virhe 2 # Error 2
make[1]: Poistutaan hakemistosta "/home/esa/qtonpi/qt5/qtbase/src" # Leaving directory
make: *** [sub-src-make_first] Virhe 2 # Error 2
Fix the paths of the libraries in your sysroot. Some libraries are symlinks to absolute paths which are broken when placed in your system. Check something like /home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.so or similar. You should see those are broken symlinks to absolute paths. Fix all of those. In the documents you reported a script for this purpose is provided. Did you run it (https://gitorious.org/cross-compile-tools/cross-compile-tools/blobs/master/fixQualifiedLibraryPaths)?
Try also to check this if you still encounter troubles: I wrote down some notes compiling a recent version from the git for the wheezy image.
An answer for those who tried both the existing answers and they didn't work:
It might happen that the Raspbian image you downloaded doesn't contain symlinks for libdl and libdm in the /usr/lib/ folder.
In that case the fixQualifiedLibraryPaths won't help you as it can't find the symlinks. Copying libdl.so and libm.so might also fail, for example, if you use a flash drive to copy data from your existing Raspberry Pi, it won't copy them as symlinks, but will copy the libraries themselves. However, for the build to succeed, it seems to require symlinks.
I looked at what libdl and libdm in the /usr/lib/ folder of my Raspberry Pi point at
cd /usr/lib/arm-linux-gnueabihf/
ls -l libld.so libm.so
Do the same for the found files until they are no longer symlinks but normal files.
On my system it turned out they are called libdl-2.13.so and libm-2.13.so and reside in /lib/arm-linux-gnueabihf/ instead of /usr/lib/...
Going back to my PC, I found these exact files in the /lib/arm-linux-gnueabihf/ folder (if you don't find them, you can copy them from your Raspberry Pi). So I created symlinks for them in the /usr/lib/arm-linux-gnueabihf/ folder :
sudo ln -s /lib/arm-linux-gnueabihf/libdl-2.13.so /usr/lib/arm-linux-gnueabihf/libdl.so
sudo ln -s /lib/arm-linux-gnueabihf/libm-2.13.so /usr/lib/arm-linux-gnueabihf/libm.so
After this, qtbase was compiled successfully.
(note, that in order to continue to cross-compile from Qt, you have to
keep the image of your SD card mounted on your PC (as described in
the guide), but that's not enough: you have to mount it before
starting Qt Creator)
Try this
ln -s /mnt/raspberry-rootfs/lib/arm-linux-gnueabihf /lib/
Basically it seems that absolute path(s) have been specified when the so files on the Pi were linked (/lib/), and therefore in the /mnt/raspberry-rootfs they are broken.
Linking the Pi's /lib/arm-linux-gnueabihf to the Pc's /lib directory fixes the wrong linking and allows QT to compile. It's a dirty trick but it works.
If you don't have libdl/ libm on the Pi, then you need to stick the SD card back into the Pi, boot and install them. Obviously you will need to create a new image on the PC from the SD Card and mount it on /mnt/raspberry-rootfs
This could be because libdl.so and libm.so are missing from your local rootfs/usr/lib/arm-linux-gnueabihf directory (there are only libdl.a and libm.a). Copying the two files from the Raspberry Pi should make the compilation successful.
instead of fixQualifiedLibraryPaths use:
cd <folder-with-sysroot-subfolder>
wget https://raw.githubusercontent.com/riscv/riscv-poky/master/script/sysroot-relativelinks.py
chmod +x sysroot-relativelinks.py
./sysroot-relativelinks.py sysroot

Resources