It seems like a bug in gcc 10 to me. IIUC, static local variables in
inline functions should still have internal linkage, and so name
collisions like this should not occur.
I can work around this by making sure that 'fun' is given different
names in the RcppEigen stubs; e.g. fun1 and fun2 and so on. The fact
that this actually works makes me think it might be a gcc bug.
On Sat, Feb 8, 2020 at 3:18 PM Iñaki Ucar <iu...@fedoraproject.org> wrote:
>
> On Sat, 8 Feb 2020 at 23:50, Dirk Eddelbuettel <e...@debian.org> wrote:
> >
> >
> > On 8 February 2020 at 22:36, Iñaki Ucar wrote:
> > | lme4 fails to compile with this misterious message in Fedora Rawhide
> > | with gcc10 (see the build log and more details in [1]). There is no
> > | "fun" in lme4, but there are several local definitions of "fun" in
> > | RcppEigen, used by lme4, under inst/include/RcppEigenStubs.h. These
> >
> > Shouldn't what is in RcppEigen be protected by namespaces?
> >
> > Also, the ever-vigilant Prof Ripley emailed dozens of people last year about
> > gcc10 changes (for C, though). If this were systemic I cam sure we'd hear
> > from him.
>
> Prof. Ripley was probably looking for issues listed in the gcc 10
> porting guide (omissions of "extern" in C, and argument mismatches in
> Fortran). This is about C linkage in a C++ package, and a quite
> strange error: lme4 is the only package on CRAN showing this issue
> with RcppEigen, so maybe it went unnoticed.
>
> > | are the relevant lines from the assembler output:
> > |
> > | fun:
> > | .zero 8
> > | .section .rodata
> > | .LC5:
> > | .string "cholmod_free_factor"
> > |
> > | ...
> > |
> > | fun:
> > | .zero 8
> > | .section .rodata
> > | .LC8:
> > | .string "cholmod_start"
> > |
> > | So it seems that, unless lme4 is doing something improper in
> > | src/lme4CholmodDecomposition.h, this is a bug in RcppEigen due to the
> > | use of inline and static (or in gcc 10?). Thoughts? Should I open an
> > | issue in RcppEigen?
> >
> > Better yet, provide a fix?
>
> I'd be more than happy to provide a fix, but I have no clue about
> what's happening here, why gcc 10 generates duplicated symbols for
> these functions (where previous versions did not), and where is the
> issue to fix (lme4, RcppEigen or even gcc 10). And that's why I'm
> posting here.
>
> > You're the one with a reproducible system :)
>
> How so, gcc 10 is all it's needed. And Fedora Rawhide can be used
> through docker to avoid the burden of installing a new toolchain:
>
> $ docker run -it --rm fedora:rawhide
> $ dnf install R
> $ Rscript -e 'install.packages("lme4", repos="https://cloud.r-project.org";)'
>
> Iñaki
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
