The 'large' is AFAICT irrelevant, the same problems arise with small ones too. In a nutshell you can do Rcpp Modules, but you have to create the interface yourself and that is tedious at scale (also no inheritance, limits due to C on different signatures for same function name etc pp) so an alternative has sometimes been to keep / instantiate a pointer to an object from your library. As in #1439, great questions (and not sure it helps we already duplicate them less than five minutes in...)

gdalraster definitely meets the description of R package providing access to a large C/C++ library (in the sense of direct and fairly complete API bindings to GDAL). It also makes extensive use of Rccp exposed class (part of modules), which provides a natural interface to the underlying class-based library. No automation though in my case. "Tedious at scale" is accurate for sure but Rcpp modules provides a lot to like if you're going to do it manually IMHO. The limitations mentioned can be an issue and good to consider up front, but there is also a lot of flexibility and decent work arounds for some of that.

I'm not a fan of Modules, although I can see the appeal for a class-based library. However, we are talking about a C library here, so IMHO I don't see the point, because you'll be doing twice the work: (1) figure out a good class-based wrapper, (2) then expose it. A C++ class-based library at least gives you (1).