Package Details: cdo 2.3.0-0

Git Clone URL: https://aur.archlinux.org/cdo.git (read-only, click to copy)
Package Base: cdo
Description: Command line tool manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG.
Upstream URL: https://code.zmaw.de/projects/cdo
Licenses: BSD
Submitter: graziano
Maintainer: ram
Last Packager: ram
Votes: 18
Popularity: 0.000005
First Submitted: 2006-12-18 15:21 (UTC)
Last Updated: 2023-10-20 09:21 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

Vassily commented on 2021-01-12 11:40 (UTC) (edited on 2021-01-12 14:43 (UTC) by Vassily)

I was unable to install cdo 1.9.9 on Manjaro Linux using GCC 10.2.0-4. A failure occurred in build() emos ... make[1]: [CMakeFiles/Makefile2:1513: libemos-sp/CMakeFiles/emos_sp.dir/all] Error 2 make: [Makefile:182: all] Error 2

Resolved. When compiling dependencies with GCC 10.2.0, use the flags: export FCFLAGS = "- w -fallow-argument-mismatch -O2" export FFLAGS = "- w -fallow-argument-mismatch -O2"

mdeff commented on 2020-12-03 20:45 (UTC)

Upstream moved to https://code.mpimet.mpg.de/projects/cdo. Both url and source could be updated.

bakamotokatas commented on 2020-04-22 19:32 (UTC) (edited on 2020-04-22 19:33 (UTC) by bakamotokatas)

Although I have installed gcc. It gives the below error.

checking for gcc... gcc checking whether the C compiler works... no configure: error: in /var/tmp/pamac-build-bakamotokatas/cdo/src/cdo-1.9.8': configure: error: C compiler cannot create executables Seeconfig.log' for more details ==> ERROR: A failure occurred in build(). Aborting...

ram commented on 2019-04-11 19:03 (UTC)

@moOzi this is again magigs++ - it needs to be updated before re-installing cdo

mo0zi commented on 2019-04-11 14:35 (UTC)

after successful installation of version 1.9.6 this error occured: $ cdo --version: /bin/cdo: error while loading shared libraries: libnetcdf.so.13: cannot open shared object file: No such file or directory. Solution: $ sudo ln -s /usr/lib/libnetcdf.so.15 /usr/lib/libnetcdf.so.13

ram commented on 2018-05-27 11:27 (UTC) (edited on 2018-05-27 11:28 (UTC) by ram)

looks good to me. other maintainers have to be convinced, too in order to make it working. IMO the numbering of shared objects is a flaw, it contradicts with the concept of shared being loaded at runtime. so why numbering them. i see the benefits regarding security, but i thought they are there to prevent the need of recompiling stuff....

Vitrum-cnkj34kr8 commented on 2018-05-27 11:14 (UTC) (edited on 2018-05-27 11:20 (UTC) by Vitrum-cnkj34kr8)

Got it. Do you think repkg's rules is a solution in such situation? However it should be employed by magics++ too.

ram commented on 2018-05-27 08:21 (UTC)

reinstallation doesn't help because magics++ needs libproj, too. you have to reinstall first magics++ and then cdo. that's how solved it on my box

Vitrum-cnkj34kr8 commented on 2018-05-26 22:39 (UTC) (edited on 2018-05-27 07:56 (UTC) by Vitrum-cnkj34kr8)

After updating proj to 5.0.1-1 (libproj.so.13), cdo stopped working:

cdo: error while loading shared libraries: libproj.so.12: cannot open shared object file: No such file or directory

Reinstall doesn't help. I made a symlink:

sudo ln -s /usr/lib/libproj.so.13.0.1 /usr/lib/libproj.so.12

Seems to works correct now...

P.S. Bug is similar to the previous one with libhdf5.

« First ‹ Previous 1 2 3 4 Next › Last »