libosmium no longer successfully builds after `v2.17.1` on CentOS 7

hummeltech commented 2 years ago

What version of libosmium are you using?

v2.17.3

What operating system and compiler are you using?

CentOS 7, gcc 4.8.5, cmake 2.8.12.2

Tell us something about your system

32GB RAM, 8 CPUs, bare metal

What did you do exactly?

docker run --rm --interactive --tty centos:7 bash
yum install --assumeyes epel-release
yum install --assumeyes \
    boost-devel \
    bzip2-devel \
    cmake \
    doxygen \
    expat-devel \
    gcc-c++ \
    gdal-devel \
    geos-devel \
    git \
    graphviz \
    lz4-devel \
    make \
    proj-devel \
    ruby \
    rubygem-json \
    sparsehash-devel \
    zlib-devel
cd ~
rm -rf libosmium protozero
git clone --quiet --depth 1 --recurse-submodules https://github.com/osmcode/libosmium.git
git clone --quiet --depth 1 https://github.com/mapbox/protozero.git
mkdir libosmium/build
cd libosmium/build
export CC=gcc
export CXX=g++
export CXXFLAGS="-Wno-missing-field-initializers -Wno-unused-parameter"
export LANG=en_US.UTF-8
cmake \
  -DBUILD_DATA_TESTS=ON \
  -DCMAKE_BUILD_TYPE=Dev \
  -DPROTOZERO_INCLUDE_DIR=../../protozero/include \
  -DUSE_CPP_VERSION=c++11 \
  -DWITH_PROJ=ON \
  -LA \
  ..
make VERBOSE=1

What did you expect to happen?

I expected the build to complete successfully.

What did happen instead?

The build did not complete successfully.

Scanning dependencies of target index_test_dump_and_load_index
make[2]: Leaving directory `/libosmium/build'
make -f test/CMakeFiles/index_test_dump_and_load_index.dir/build.make test/CMakeFiles/index_test_dump_and_load_index.dir/build
make[2]: Entering directory `/libosmium/build'
/usr/bin/cmake -E cmake_progress_report /libosmium/build/CMakeFiles 
[ 66%] Building CXX object test/CMakeFiles/index_test_dump_and_load_index.dir/t/index/test_dump_and_load_index.cpp.o
cd /libosmium/build/test && /usr/bin/g++   -DOSMIUM_WITH_LZ4 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wno-missing-field-initializers  -O3 -g -I/libosmium/include -isystem /protozero/include -isystem /usr/include/gdal -isystem /libosmium/test/catch -I/libosmium/test/include    -std=c++11 -Werror -Wall -Wextra -pedantic -Wredundant-decls -Wdisabled-optimization -Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wsign-promo -Wold-style-cast -Wno-parentheses -Wno-deprecated-declarations -o CMakeFiles/index_test_dump_and_load_index.dir/t/index/test_dump_and_load_index.cpp.o -c /libosmium/test/t/index/test_dump_and_load_index.cpp
In file included from /libosmium/include/osmium/index/map/dense_file_array.hpp:38:0,
                 from /libosmium/test/t/index/test_dump_and_load_index.cpp:4:
/libosmium/include/osmium/index/detail/vector_map.hpp: In instantiation of ‘class osmium::index::map::VectorBasedDenseMap<std::vector<osmium::Location, std::allocator<osmium::Location> >, long unsigned int, osmium::Location>’:
/libosmium/test/t/index/test_dump_and_load_index.cpp:64:72:   required from here
/libosmium/include/osmium/index/detail/vector_map.hpp:72:38: error: function ‘osmium::index::map::VectorBasedDenseMap<TVector, TId, TValue>& osmium::index::map::VectorBasedDenseMap<TVector, TId, TValue>::operator=(osmium::index::map::VectorBasedDenseMap<TVector, TId, TValue>&&) [with TVector = std::vector<osmium::Location, std::allocator<osmium::Location> >; TId = long unsigned int; TValue = osmium::Location]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘osmium::index::map::VectorBasedDenseMap<std::vector<osmium::Location, std::allocator<osmium::Location> >, long unsigned int, osmium::Location>& osmium::index::map::VectorBasedDenseMap<std::vector<osmium::Location, std::allocator<osmium::Location> >, long unsigned int, osmium::Location>::operator=(osmium::index::map::VectorBasedDenseMap<std::vector<osmium::Location, std::allocator<osmium::Location> >, long unsigned int, osmium::Location>&&)’
                 VectorBasedDenseMap& operator=(VectorBasedDenseMap&&) noexcept = default;
                                      ^
In file included from /libosmium/include/osmium/index/map/dense_file_array.hpp:38:0,
                 from /libosmium/test/t/index/test_dump_and_load_index.cpp:4:
/libosmium/include/osmium/index/detail/vector_map.hpp: In instantiation of ‘class osmium::index::map::VectorBasedSparseMap<long unsigned int, osmium::Location, osmium::index::map::StdVectorWrap>’:
/libosmium/test/t/index/test_dump_and_load_index.cpp:82:73:   required from here
/libosmium/include/osmium/index/detail/vector_map.hpp:194:39: error: function ‘osmium::index::map::VectorBasedSparseMap<TId, TValue, TVector>& osmium::index::map::VectorBasedSparseMap<TId, TValue, TVector>::operator=(osmium::index::map::VectorBasedSparseMap<TId, TValue, TVector>&&) [with TId = long unsigned int; TValue = osmium::Location; TVector = osmium::index::map::StdVectorWrap]’ defaulted on its first declaration with an exception-specification that differs from the implicit declaration ‘osmium::index::map::VectorBasedSparseMap<long unsigned int, osmium::Location, osmium::index::map::StdVectorWrap>& osmium::index::map::VectorBasedSparseMap<long unsigned int, osmium::Location, osmium::index::map::StdVectorWrap>::operator=(osmium::index::map::VectorBasedSparseMap<long unsigned int, osmium::Location, osmium::index::map::StdVectorWrap>&&)’
                 VectorBasedSparseMap& operator=(VectorBasedSparseMap&&) noexcept = default;
                                       ^
make[2]: *** [test/CMakeFiles/index_test_dump_and_load_index.dir/t/index/test_dump_and_load_index.cpp.o] Error 1

What did you do to try analyzing the problem?

Going back to v2.17.1 works just fine. I also created a branch here which fixes the build issues, leaving just a few test failures needing resolution. See here for a workflow run showing all jobs building successfully.

joto commented 2 years ago

Thanks for looking into this, but it is unlikely that I'll get around to work on this. There are a several problems with those old compilers, sometimes they can't be fixed without generating problems with new compilers or upsetting clang-tidy and it becomes increasingly difficult to maintain this. So something just has to give. And Centos 7 is more than 7 years old by now! Sorry, but unless a sponsor is willing to put some money into this, I'll can not keep up compatibility in all cases.

hummeltech commented 2 years ago

Yeah, I suppose you're right, it's a shame that this breaking change was introduced in a minor point release and that distributions like RHEL/CentOS 7, which will still be supported for another 2.5 years, are still so widely used. Either way, I have pinpointed the breaking locations and made a small change in a commit here which does fix the build errors (albeit certainly not in the best way), perhaps I can dive into it more in order to identify a proper fix.

osmcode / libosmium