search

eddelbuettel / bh

R package providing Boost Header files
85 stars 33 forks source link

Installation error r-devel-linux-x86_64-debian-gcc #83

Closed JeremyGelb closed 2 years ago

JeremyGelb commented 2 years ago

Dear all,

I am the maintainer of the package spNetwork, which is using BH to access the boost geometry library. I received a message from CRAN indicating that an error is occurring now for the installation of spNetwork on r-devel-linux-x86_64-debian-gcc. The error seems to be related to BH compilation (see the report here : https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/spNetwork-00install.html), but I have no clue about what is happening.

Do you have an suggestion about it ?

Thank you for your help.

eddelbuettel commented 2 years ago

(I so hate how CRAN forces me to keep all the noise in the compilation. )

Hm, with things like

/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/get_pointer.hpp:48:40: warning: ‘template<class> class std::auto_ptr’ is deprecated: use 'std::unique_ptr' instead [-Wdeprecated-declarations]
   48 | template<class T> T * get_pointer(std::auto_ptr<T> const& p)
      |                                        ^~~~~~~~
In file included from /usr/include/c++/12/memory:76,
                 from /home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/function/function_base.hpp:16,
                 from /home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/function/detail/prologue.hpp:17:
/usr/include/c++/12/bits/unique_ptr.h:56:28: note: declared here
   56 |   template<typename> class auto_ptr;
      |                            ^~~~~~~~
In file included from /home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/strategies/geographic/distance.hpp:38,
                 from /home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/strategies/strategies.hpp:90:
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp: In member function ‘void boost::geometry::model::d2::point_xy<CoordinateType, CoordinateSystem>::x(const CoordinateType&)’:
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp:69:27: error: type/value mismatch at argument 1 in template parameter list for ‘template<class _Key, class _Compare, class _Alloc> class std::set’
   69 |     { this->template set<0>(v); }
      |                           ^
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp:69:27: note:   expected a type, got ‘0’
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp:69:27: error: template argument 2 is invalid
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp:69:27: error: template argument 3 is invalid

I fear this is between you and Boost. I can't help.

Did it work with older BH (and Boost) releases? Did it work with other compilers?

eddelbuettel commented 2 years ago

Actually, I can answer that -- as I of course also run spNetwork when I run all reverse-depends for Rcpp (or BH). So it seems like it may be an issue with newer compilers only? Little I can do then in the released version of BH.

JeremyGelb commented 2 years ago

Thank you for your quick answer. So the problem is caused by the use of a new compiler and some specific the boost library itself. There is only little thing we can do at our level. I will contact CRAN to ask them what I can do with this issue. (and sorry for the messy error message from CRAN). Il will post the answer from CRAN here.

eddelbuettel commented 2 years ago

Sounds good. For what it is worth I have tested spNetwork, and the rest of the Rcpp reverse dependencies, a few times in the last few days. No issues with g++-11.

JeremyGelb commented 2 years ago

Well, here is teh response from CRAN :

Thanks. As I wrote, this is new with moving from the GCC 11 compilers to a prerelease snapshot of the GCC 12 compilers. The fedora checks will eventually move to the GCC 12 compilers too, so we really need to have CRAN packages compile ok with these. If the problem is not in BH, then it is either in your code or a bug in the compilers: I unfortunately do not speak enough C++ to see which. I tried asking Dr Google for help but did not get very far: perhaps you can fare better?

Is spNetwork the only package for which this issue was raised during reverse dependenciy checks ?

eddelbuettel commented 2 years ago

That is something you have to ask CRAN -- I still use gcc/g++ release 11, the default in Debian testing.

There were some recent other issues uncovered by newer compilers, eg clang was warning about the deprecated std::unary_function() and std::binary_function() so I helped with Rcpp hotfix release 1.0.8.2 which switched that. But that was just a harmless warning, not an error.

I think there are only a handful of packages depending on BH for Boost Geometry -- maybe search the issues here as IIRC this once forced us to turn C++14 on for those -- so you may discuss with them and get upstream involved.

I am really just the middleman here aggregating the Boost headers as a convenience for about 279 packages in total.

eddelbuettel commented 2 years ago

We could also try to bring it to the r-package-devel list. Uwe replies there every now and then, and I do not know who you spoke with at CRAN. I cannot really help you here.

JeremyGelb commented 2 years ago

Alright, thank you again for the insights. I will investigate on my side with the links you suggested.

eddelbuettel commented 2 years ago

I can possibly help with proper setups. Docker is a good tool, the r-base container is close as you can insta;; g++-12 and just have to select it via CXX or CXX17.

Speaking of which, one thought I had was: can you change the the C++ standard away from C++17? Not sure if it makes a difference...

JeremyGelb commented 2 years ago

Good point, I will start with this and try to replicate the error. If changing the C++ required version can solve the problem, it would be great.

eddelbuettel commented 2 years ago

Yes, as I mentioned above I ran R CMD check --as-cran against your package (and the 2500+ others that use Rcpp) and I had zero issues using g++-11. CRAN is of course forward-looking and wants to achieve the same for g++-12 but that may turn out to be not that be easy.

eddelbuettel commented 2 years ago

A friend reminded me that I created a 'R + bleeding edge compiler' container a while back for gcc-11 -- right time now to update for gcc-12 (and g++-12). It's Ubuntu based and possibly slightly different from what Kurt Hornik runs in Vienna, but on the other it exists now :) If Docker helps you consider this: https://hub.docker.com/r/rocker/r-edge/tags and gcc-12 or just latest is what you want here.

jhnwllr commented 2 years ago

Hello @eddelbuettel is there any progress on this?

I am the new maintainer of the wellknown package, which gets this same error on CRAN checks. https://cran.r-project.org/web/checks/check_results_wellknown.html

Any advice?

eddelbuettel commented 2 years ago

@jhnwllr I don't think there was anything actionable for me here. Those all appear to upstream issue in Boost. Did you or @JeremyGelb talk to them? I provide BH as a convenience, I cannot take active development upstream on,

JeremyGelb commented 2 years ago

Hello !

Sorry for the delay. I tried to reproduce the error with the Docker suggested by @eddelbuette https://github.com/eddelbuettel, and it was a real pain. I am not done with it, but it seems that the error is linked to the use of a rtree structure.

geometrical_functions.cpp:99:18: required from here

/usr/local/lib/R/site-library/BH/include/boost/concept/usage.hpp:20:48: warning: ‘this’ pointer is null [-Wnonnull]

20 | ~usage_requirements() { ((Model*)0)->~Model(); }

  |                             ~~~~~~~~~~~~~~~~~~~^~

/usr/local/lib/R/site-library/BH/include/boost/concept/usage.hpp:37:7: note: in a call to non-static member function ‘boost::DefaultConstructible::~DefaultConstructible() [with TT = boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::d2::point_xy

, int>, boost::geometry::index::quadratic<16>, boost::geometry::model::box<boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<boost::container::new_allocator<std::pair<boost::geometry::model::box<boost::geometry::model::d2::point_xy , int> >, std::pair<boost::geometry::model::box<boost::geometry::model::d2::point_xy , int>, boost::geometry::index::quadratic<16>, boost::geometry::model::box<boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian> >, int>, boost::geometry::index::quadratic<16, 4>, boost::geometry::model::box<boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<boost::container::new_allocator<std::pair<boost::geometry::model::box<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian> >, int> >, std::pair<boost::geometry::model::box<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian> >, int>, boost::geometry::index::quadratic<16, 4>, boost::geometry::model::box<boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag> >>]’

37 | ~model()

  |       ^

/usr/local/lib/R/site-library/BH/include/boost/concept_check.hpp:137:5: note: in expansion of macro ‘BOOST_CONCEPT_USAGE’

137 | BOOST_CONCEPT_USAGE(DefaultConstructible) {

  |     ^~~~~~~~~~~~~~~~~~~

make: *** [/usr/lib/R/etc/Makeconf:177: geometrical_functions.o] Error 1

ERROR: compilation failed for package ‘spNetwork’

  • removing ‘/tmp/Rtmpr7lt6M/file870724d94/spNetwork.Rcheck/spNetwork’

in the file geometrical_functions.cpp at the line 99 I have :

typedef std::pair<bbox, int> rtree_element; typedef bgi::rtree< rtree_element, bgi::quadratic<16>> lines_rtree;

lines_rtree build_rtree_for_lines(lines_vector lines){

// This is the classical way // // setting the empty rtree lines_rtree mytree; bbox abox;

// iterating over the lines int i = 0; for(i = 0 ; i < lines.size() ; i++){ bg::envelope(lines[i], abox); rtree_element el = std::make_pair(abox, i); mytree.insert(el); }

And here are the defined types and loaded libraries :

include "spNetwork.h"

include "matrices_functions.h"

// some boost libraries used to building an rtree

include <boost/geometry.hpp>

include <boost/geometry/geometries/geometries.hpp>

include <boost/geometry/geometries/point.hpp>

include <boost/geometry/geometries/box.hpp>

include <boost/geometry/index/rtree.hpp>

include <boost/geometry/algorithms/distance.hpp>

include <boost/foreach.hpp>

include <boost/geometry/index/predicates.hpp>

// some namespaces related to boost namespace bg = boost::geometry; namespace bgi = boost::geometry::index;

// * some global types used

// basic geometries typedef bg::model::d2::point_xy point_t; typedef bg::model::linestring linestring_t; typedef bg::model::box bbox;

// a simple vector of boost lines typedef std::vector lines_vector;

I will let you know if I find something more specific.

Le ven. 1 avr. 2022 à 09:15, Dirk Eddelbuettel @.***> a écrit :

@jhnwllr https://github.com/jhnwllr I don't think there was anything actionable for me here. Those all appear to upstream issue in Boost. Did you or @JeremyGelb https://github.com/JeremyGelb talk to them? I provide BH as a convenience, I cannot take active development upstream on,

— Reply to this email directly, view it on GitHub https://github.com/eddelbuettel/bh/issues/83#issuecomment-1085887760, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALFPUINFF2FPC6BHPHWPZETVC3ZHVANCNFSM5QV2ZSJA . You are receiving this because you were mentioned.Message ID: @.***>

--

Jérémy GELB Assistant de recherche à l'INRS Docteur en Études Urbaines

514 658 6054 @.*** F-4221 Avenue Coloniale H2W2C3 Montréal Quebec

eddelbuettel commented 2 years ago

Have you had a chance to check on upstream? We are at a fairly recent Boost release but maybe they have encountered the compiler issues too?

JeremyGelb commented 2 years ago

It seems that boost 1.78 was not tested for gcc12 : https://www.boost.org/users/history/version_1_78_0.html

Enchufa2 commented 2 years ago

As I told @JeremyGelb by mail, I see:

using namespace std;

in spNetwork.h, which is generally a bad idea with Boost, and then:

In file included from /home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/strategies/geographic/distance.hpp:38,
                 from /home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/strategies/strategies.hpp:90:
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp: In member function ‘void boost::geometry::model::d2::point_xy<CoordinateType, CoordinateSystem>::x(const CoordinateType&)’:
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/BH/include/boost/geometry/geometries/point_xy.hpp:69:27: error: type/value mismatch at argument 1 in template parameter list for ‘template<class _Key, class _Compare, class _Alloc> class std::set’
   69 |     { this->template set<0>(v); }
      |                           ^

in the error above, which precisely complains about std::set. So, first of all, I would drop that using namespace std;, qualify whatever is needed from the std namespace, and see what happens.

eddelbuettel commented 2 years ago

Nice catch and concur 100% --- flattening namespaces can have 'surprising' (read: undesired) side effects that can also be tricky to deciper. Esp when our good friends at CRAN force us to message quietening off and Boost and Eigen drown you in noise (unless you locally add compiler flags).

JeremyGelb commented 2 years ago

Wow, the package is now compiling on the Docker you recommended to me. Thank you @Enchufa2 and @eddelbuettel, I hope it will work on the CRAN server. I will do some cleaning, and I plan to submit it this week. Do you know if there is another way for me to be sure it will work this time? It seems that rhub r-devel-linux-x86_64-debian-gcc uses gcc-8.04. I tried to set up a Virtual Machine with Linux 18 but I could not install gcc-12.

eddelbuettel commented 2 years ago

Good to know!

May be a good idea to report back to the list too as the std:: namespace pollution can in fact happen, especially when compilers versions change as that sometimes brings in new headers.

Enchufa2 commented 2 years ago

Wow, the package is now compiling on the Docker you recommended to me.

Great!

Thank you @Enchufa2 and @eddelbuettel, I hope it will work on the CRAN server. I will do some cleaning, and I plan to submit it this week. Do you know if there is another way for me to be sure it will work this time? It seems that rhub r-devel-linux-x86_64-debian-gcc uses gcc-8.04. I tried to set up a Virtual Machine with Linux 18 but I could not install gcc-12.

The only way to be 100% sure is by submitting to CRAN. But I'd say we're like 99% sure now. ;-)

May be a good idea to report back to the list too as the std:: namespace pollution can in fact happen, especially when compilers versions change as that sometimes brings in new headers.

Agree. Please, report back to the r-package-devel list, maybe linking this issue, so that the solution is available for other developers incurring similar errors.

JeremyGelb commented 2 years ago

Hey ! I just forgot to do the following up here. The problem is solved and the namespace pollution was the cause of the error. Feel free to close the issue. Thank you a lot for your help !

eddelbuettel commented 2 years ago

Great news, and good to know. In hindsight it always seems obvious nomatter how befuddling it appears while chasing the issue.