Search Criteria
Package Details: cdo 1.9.7.1-0
| Git Clone URL: | https://aur.archlinux.org/cdo.git (read-only) |
|---|---|
| Package Base: | cdo |
| Description: | Command line tool manipulate and analyse Climate model Data. Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more than 400 operators available. |
| Upstream URL: | https://code.zmaw.de/projects/cdo |
| Licenses: | |
| Submitter: | graziano |
| Maintainer: | ram |
| Last Packager: | ram |
| Votes: | 13 |
| Popularity: | 0.014426 |
| First Submitted: | 2006-12-18 15:21 |
| Last Updated: | 2019-06-14 09:53 |
Dependencies (20)
- curl (curl-http2-git, curl-git)
- eccodes
- fftw (fftw-mpich, fftw-mpi)
- hdf5 (hdf5-java, hdf5-openmpi-java, hdf5-openmpi)
- jasper
- libaec
- magics++
- netcdf (netcdf-openmpi)
- proj (proj-configure-git, proj-git)
- udunits
- curl (curl-http2-git, curl-git) (make)
- eccodes (make)
- fftw (fftw-mpich, fftw-mpi) (make)
- hdf5 (hdf5-java, hdf5-openmpi-java, hdf5-openmpi) (make)
- jasper (make)
- libaec (make)
- magics++ (make)
- netcdf (netcdf-openmpi) (make)
- proj (proj-configure-git, proj-git) (make)
- udunits (make)
Latest Comments
1 2 3 Next › Last »
ram commented on 2019-04-11 19:03
@moOzi this is again magigs++ - it needs to be updated before re-installing cdo
mo0zi commented on 2019-04-11 14:35
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
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
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
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
After updating
projto 5.0.1-1 (libproj.so.13),cdostopped working:Reinstall doesn't help. I made a symlink:
Seems to works correct now...
P.S. Bug is similar to the previous one with
libhdf5.ram commented on 2018-01-20 22:19
sure - no problem. thx for the hint
mpejcoch commented on 2018-01-18 13:53
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?
ram commented on 2017-07-06 14:29
Because of gcc update to gcc-7, please rebuild eccodes and magics++ (in that order)
ram commented on 2017-05-04 13:22
Please recompile CDO port with recent magics++ 2.32.0.