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.000756
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 »

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.

ram commented on 2018-01-20 22:19 (UTC)

sure - no problem. thx for the hint

mpejcoch commented on 2018-01-18 13:53 (UTC)

There seems to be some conflict now with libaec, as that one is providing libszip and is required by hdf5. Could you switch the requirements for cdo to be libaec instead of szip?