Arch Linux User Repository

Hi Jan, Thanks for this update. I confirm it works for me too now.

During compilation, I observed some ODR violations warnings (see below), perhaps this explains that. Maybe this should be reported upstream ?

/home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/src/eccodes/grib_hash_keys.cc:11739:8: warning: type ‘struct grib_itrie’ violates the C++ One Definition Rule [-Wodr]
11739 | struct grib_itrie
      |        ^
/home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/src/eccodes/grib_itrie.cc:278:8: note: a different type is defined in another translation unit
  278 | struct grib_itrie
      |        ^
/home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/src/eccodes/grib_hash_keys.cc:11741:17: note: the first difference of corresponding definitions is field ‘next’
11741 |     grib_itrie* next[SIZE];
      |                 ^
/home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/src/eccodes/grib_itrie.cc:280:17: note: a field of same name but different type is defined in another translation unit
  280 |     grib_itrie* next[SIZE];
      |                 ^
/home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/src/eccodes/grib_hash_keys.cc:11739:8: note: array types have different bounds
...

Hi @Nestor_013,

I get this very error on my local machine, too, but not on my test pipelines using fresh Arch-containers. I'm not really sure what cases the problem, but I deactivated the test and re-added the download of the extra test data since it really speeds up the test process. An update of the package is on the way.

Best Jan

Hi, not sure if it's me only, but I get a crash, which prevents yay from installing, in one of the tests (see below):

 91/462 Test  #91: eccodes_t_grib_ecc-2221 ........................***Failed    0.12 sec
++ echo 'Script: /home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/tests/grib_ecc-2221.sh'
Script: /home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source/tests/grib_ecc-2221.sh
++ proj_dir=/home/user/.cache/yay/eccodes/src/eccodes-2.46.0-Source
++ build_dir=/home/user/.cache/yay/eccodes/src/build
++ data_dir=/home/user/.cache/yay/eccodes/src/build/data
++ def_dir=/home/user/.cache/yay/eccodes/src/build/share/eccodes/definitions
++ ECCODES_DEFINITION_PATH=/home/user/.cache/yay/eccodes/src/build/share/eccodes/definitions
++ export ECCODES_DEFINITION_PATH
++ tools_dir=/home/user/.cache/yay/eccodes/src/build/bin
++ bin_dir=/home/user/.cache/yay/eccodes/src/build/bin
++ EXEC=
++ test x '!=' x
++ test_dir=/home/user/.cache/yay/eccodes/src/build/tests
++ samp_dir=/home/user/.cache/yay/eccodes/src/build/share/eccodes/samples
++ ECCODES_SAMPLES_PATH=/home/user/.cache/yay/eccodes/src/build/share/eccodes/samples
++ export ECCODES_SAMPLES_PATH
++ set -u
++ HAVE_PRODUCT_BUFR=1
++ HAVE_PRODUCT_GRIB=1
++ HAVE_JPEG=1
++ HAVE_LIBJASPER=0
++ HAVE_LIBOPENJPEG=1
++ HAVE_PNG=1
++ HAVE_AEC=1
++ HAVE_GEOGRAPHY=1
++ HAVE_ECKIT_GEO=0
++ HAVE_EXTRA_TESTS=1
++ HAVE_MEMFS=0
++ ECCODES_ON_WINDOWS=0
+++ pwd
++ echo 'Current directory: /home/user/.cache/yay/eccodes/src/build/tests'
Current directory: /home/user/.cache/yay/eccodes/src/build/tests
+ label=grib_ecc-2221_test
+ tempGrib=temp.grib_ecc-2221_test.grib
+ tempFilt=temp.grib_ecc-2221_test.filt
+ sample_grib2=/home/user/.cache/yay/eccodes/src/build/share/eccodes/samples/GRIB2.tmpl
+ cat
+ /home/user/.cache/yay/eccodes/src/build/bin/grib_filter -o temp.grib_ecc-2221_test.grib temp.grib_ecc-2221_test.filt /home/user/.cache/yay/eccodes/src/build/share/eccodes/samples/GRIB2.tmpl
+ grib_check_key_equals temp.grib_ecc-2221_test.grib model,configuration,forcing,timespan 'lisflood v5 ecmf-ifs 6h'
+ a_file=temp.grib_ecc-2221_test.grib
+ a_key=model,configuration,forcing,timespan
+ a_expected='lisflood v5 ecmf-ifs 6h'
++ /home/user/.cache/yay/eccodes/src/build/bin/grib_get -p model,configuration,forcing,timespan temp.grib_ecc-2221_test.grib
ECCODES ERROR   :  timespan (Key/value not found)
+ a_result='lisflood v5 ecmf-ifs '

Hi Jan, looks like the certificate on the Arch Wiki page has expired so I'll have to defer attempting the clean Chroot build.

I am, however, by no means certain that (for all the portentousness of the "fatal error") that the Fortran fail is the final cause of failure as I don't see a connection between that and the C++ errors of the second block, and the build continues far longer than any other "waiting for unfinished jobs" that I've ever seen.

Hey @James-T tha seems odd. I updated to package to clean the build dir automatically, if existing. That should at least ensure that no remnats of old builds a present in a new build. However, I still don't get why gfortran is complaining about the LTO version. If the new pkgrel does not work, could your try building in a clean chroot as suggested in https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot?

Best Jan

@jankoh: I think the build was clean (unless I missed something), since the package had beed built & updated using yay for a while, I went to the directory with the package ($HOME/.cache/yay/eccodes) and deleted both the src and pkg directories, then ran makepkg which gave the results I have posted.

I am aware that on occasion there are version incompatibilities between Arch & Manjaro but these are usually temporary and disappear when Manjaro catches up.

$ pacman -Q gcc gcc-fortran
gcc 15.2.1+r447+g6a64f6c3ebb8-1
gcc-fortran 15.2.1+r447+g6a64f6c3ebb8-1

@James-T: Does this happen on a clean build dir? Or do you use chrooted build as recommended? I seems to me, that at least some of the objects were build using an older (fortran) compiler version causing the problems.

I changed the pkgbuild to follow Arch's CMake-build guidlines (https://wiki.archlinux.org/title/CMake_package_guidelines), so the build dir is no longer within the source-tree of the package, but outside. That might cause problems, if there are remnants of a older build in a still-existing build dir...

OTOH, I don't have a Manjaro-system available; my test pipelines run on Arch's current Develop-Container-images. So, if the Manjaro-Maintainers change some tings incompatibly, those pipelines will not catch culprits.

Best, Jan

I've not been able to build on Manjaro since V2.42.0.

Very early in the build I get the error:

[  0%] Linking Fortran executable grib_types
lto1: fatal error: bytecode stream in file ‘CMakeFiles/grib_types.dir/grib_fortran_kinds.c.o’ generated with LTO version 16.0 instead of the expected 15.1
compilation terminated.
lto-wrapper: fatal error: /usr/bin/gfortran returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [fortran/CMakeFiles/grib_types.dir/build.make:117: fortran/grib_types] Error 1
make[1]: *** [CMakeFiles/Makefile2:4195: fortran/CMakeFiles/grib_types.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

After which the build in fact continues to about 44% when:

[ 44%] Linking CXX shared library ../../lib/libeccodes.so
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_hash_keys.cc:11480:8: warning: type ‘struct grib_itrie’ violates the C++ One Definition Rule [-Wodr]
11480 | struct grib_itrie
      |        ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_itrie.cc:278:8: note: a different type is defined in another translation unit
  278 | struct grib_itrie
      |        ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_hash_keys.cc:11482:17: note: the first difference of corresponding definitions is field ‘next’
11482 |     grib_itrie* next[SIZE];
      |                 ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_itrie.cc:280:17: note: a field of same name but different type is defined in another translation unit
  280 |     grib_itrie* next[SIZE];
      |                 ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_hash_keys.cc:11480:8: note: array types have different bounds
11480 | struct grib_itrie
      |        ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_dumper_factory.cc:19:8: warning: type ‘struct table_entry’ violates the C++ One Definition Rule [-Wodr]
   19 | struct table_entry
      |        ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_iterator_factory.cc:18:8: note: a different type is defined in another translation unit
   18 | struct table_entry
      |        ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_dumper_factory.cc:22:23: note: the first difference of corresponding definitions is field ‘dumper’
   22 |     eccodes::Dumper** dumper;
      |                       ^
/home/james/.cache/yay/eccodes/src/eccodes-2.45.0-Source/src/eccodes/grib_iterator_factory.cc:21:39: note: a field with different name is defined in another translation unit
   21 |     eccodes::geo_iterator::Iterator** iterator;
      |                                       ^
[ 44%] Built target eccodes
make: *** [Makefile:166: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Not sure if the errors are related.

Hi @davroot, I see the same problem on my local machine, interestlingly my test pipeline using Arch's Dev-Container is running just fine, so I uploaded the new version suspecting it is only a local problem. You can skip tests when installing the package to get it to work. But we should probably file a bug report upstream.

UPDATE: rebooting fixed the issue on my local machine. I suspect the (parallely installed) gcc-update to likely be the cause of the problem.

Best, Jan

Hi,

The test 24 failed

Start 24: eccodes_t_grib_mtg2_switch 24/449 Test #24: eccodes_t_grib_mtg2_switch .....................***Failed

This fails all the installation