Skip to content

[Rcpp-devel] Undefined Reference to typeinfo for Rcpp::RObject for Rdisop on Mac after Rcpp/RcppClassic update

13 messages · Kevin Ushey, Dirk Eddelbuettel, Dan Tenenbaum +1 more

Original
Neumann, Steffen
# 
Hi list,

I am having issues to build Rdisop on Mac (to which I have no access)
after the upgrade to Rcpp 0.11.0 / RcppClassic 0.9.5, on both 

http://bioconductor.org/checkResults/2.13/bioc-LATEST/Rdisop/perceval-buildsrc.html
http://bioconductor.org/checkResults/2.14/bioc-LATEST/Rdisop/petty-buildsrc.html

with the same error message. Somehow the "typeinfo for Rcpp::RObject"
is not found in the shared library:

	Symbol not found: __ZTIN4Rcpp7RObjectE (typeinfo for Rcpp::RObject)
	Expected in: flat namespace

Any idea how to get back it in there ? This sounds similar 
to [1] and [2] and would hint that "someone" 
(R ? BioC build farm ?) needs to set (at compile time[3])

	export REQUIRES_RTTI=1

Thanks in advance,
Yours,
Steffen

[1] https://github.com/llvmpy/llvmpy/issues/50
[2] http://stackoverflow.com/questions/9058594/building-and-running-llvm-py-on-mac-os-x
[3] http://llvm.org/docs/Packaging.html#c-features


The system is petty:
http://bioconductor.org/checkResults/2.14/bioc-LATEST/petty-NodeInfo.html
with Mac OS X Snow Leopard (10.6.8), 
R Under development (unstable) (2014-01-15 r64790) -- "Unsuffered Consequences" 
and llvm-g++-4.2 compiler.

Installed packages here are:
http://bioconductor.org/checkResults/2.14/bioc-LATEST/petty-R-instpkgs.html
Rcpp                                            0.11.0 3.1.0
RcppClassic                                      0.9.5 3.1.0


[Don't mind the windows build failure, that comes next, 
 but it only happens on one machine so it works somewhere.]


** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object ?/private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so?:
  dlopen(/private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so, 6): Symbol not found: __ZTIN4Rcpp7RObjectE
  Referenced from: /private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so
  Expected in: flat namespace
 in /private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so
Error: loading failed


echo __ZTIN4Rcpp7RObjectE | c++filt -s auto -t  -_
typeinfo for Rcpp::RObject
Dirk Eddelbuettel
#
On 6 February 2014 at 13:05, Steffen Neumann wrote:
| Hi list,
| 
| I am having issues to build Rdisop on Mac (to which I have no access)
| after the upgrade to Rcpp 0.11.0 / RcppClassic 0.9.5, on both 
| 
| http://bioconductor.org/checkResults/2.13/bioc-LATEST/Rdisop/perceval-buildsrc.html
| http://bioconductor.org/checkResults/2.14/bioc-LATEST/Rdisop/petty-buildsrc.html
| 
| with the same error message. Somehow the "typeinfo for Rcpp::RObject"
| is not found in the shared library:
| 
| 	Symbol not found: __ZTIN4Rcpp7RObjectE (typeinfo for Rcpp::RObject)
| 	Expected in: flat namespace
| 
| Any idea how to get back it in there ? This sounds similar 
| to [1] and [2] and would hint that "someone" 
| (R ? BioC build farm ?) needs to set (at compile time[3])
| 
| 	export REQUIRES_RTTI=1

Weird. If it is on the Mac, is that with g++-4.2 or with clang ?

Dirk
 
| Thanks in advance,
| Yours,
| Steffen
| 
| [1] https://github.com/llvmpy/llvmpy/issues/50
| [2] http://stackoverflow.com/questions/9058594/building-and-running-llvm-py-on-mac-os-x
| [3] http://llvm.org/docs/Packaging.html#c-features
| 
| 
| The system is petty:
| http://bioconductor.org/checkResults/2.14/bioc-LATEST/petty-NodeInfo.html
| with Mac OS X Snow Leopard (10.6.8), 
| R Under development (unstable) (2014-01-15 r64790) -- "Unsuffered Consequences" 
| and llvm-g++-4.2 compiler.
| 
| Installed packages here are:
| http://bioconductor.org/checkResults/2.14/bioc-LATEST/petty-R-instpkgs.html
| Rcpp                                            0.11.0 3.1.0
| RcppClassic                                      0.9.5 3.1.0
| 
| 
| [Don't mind the windows build failure, that comes next, 
|  but it only happens on one machine so it works somewhere.]
| 
| 
| ** testing if installed package can be loaded
| Error in dyn.load(file, DLLpath = DLLpath, ...) : 
|   unable to load shared object ?/private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so?:
|   dlopen(/private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so, 6): Symbol not found: __ZTIN4Rcpp7RObjectE
|   Referenced from: /private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so
|   Expected in: flat namespace
|  in /private/tmp/RtmpoagsNv/Rinst13f9973b0c29a/Rdisop/libs/Rdisop.so
| Error: loading failed
| 
| 
| echo __ZTIN4Rcpp7RObjectE | c++filt -s auto -t  -_
| typeinfo for Rcpp::RObject
| 
| 
| -- 
| IPB Halle                    AG Massenspektrometrie & Bioinformatik
| Dr. Steffen Neumann          http://www.IPB-Halle.DE
| Weinberg 3                   http://msbi.bic-gh.de
| 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
|                                   +49 (0) 345 5582 - 0
| sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
| 
| 
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Neumann, Steffen
# 
Hi,
On Thu, 2014-02-06 at 07:54 -0600, Dirk Eddelbuettel wrote:
...
...
I don't know the terminology in llvm land, 
the BioC system information page says "llvm-g++-4.2",
and there is more about the build environment on
Did that help ? Otherwise we need input from Dan or Kevin.

Yours,
Steffen
Dirk Eddelbuettel
#
On 6 February 2014 at 15:15, Steffen Neumann wrote:
| Hi,
|
| On Thu, 2014-02-06 at 07:54 -0600, Dirk Eddelbuettel wrote:
| ...
| > Weird. If it is on the Mac, is that with g++-4.2 or with clang ?
| ...
| > | and llvm-g++-4.2 compiler.
| 
| I don't know the terminology in llvm land, 
| the BioC system information page says "llvm-g++-4.2",
| and there is more about the build environment on 

That's the old standard compiler that Simon still builds R with too.  I would
not know why it suddenly needs an RTTI switch.

Dirk
 
| > | http://bioconductor.org/checkResults/2.14/bioc-LATEST/petty-NodeInfo.html
| 
| Did that help ? Otherwise we need input from Dan or Kevin.
| 
| Yours,
| Steffen
| 
| 
| -- 
| IPB Halle                    AG Massenspektrometrie & Bioinformatik
| Dr. Steffen Neumann          http://www.IPB-Halle.DE
| Weinberg 3                   http://msbi.bic-gh.de
| 06120 Halle                  Tel. +49 (0) 345 5582 - 1470
|                                   +49 (0) 345 5582 - 0
| sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409
|
Kevin Ushey
# 
I wonder if the 'typeid' error could be a red herring and the real
cause could be somehow related to virtual functions. If the compiler
didn't know what 'typeid' meant (ie, had no RTTI) it would have failed
on compilation, not linking, no? E.g.:
http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo

I'll try to see if I can figure something out.

-Kevin
On Thu, Feb 6, 2014 at 6:34 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
Kevin Ushey
# 
Apparently this is moot now, because it looks like Rdisop now builds
successfully on BioC for all systems:
http://bioconductor.org/checkResults/2.14/bioc-LATEST/Rdisop/petty-buildsrc.html,
http://bioconductor.org/checkResults/2.13/bioc-LATEST/Rdisop/perceval-buildsrc.html.

Did you have to change something in your package, or was it related to
the BioC build system?

Thanks,
Kevin
On Thu, Feb 6, 2014 at 10:41 AM, Kevin Ushey <kevinushey at gmail.com> wrote:
Dan Tenenbaum
# 
----- Original Message -----
The build system was pulling down a binary version of RcppClassic but it needs to be built from source.

Dan
Dan Tenenbaum
# 
----- Original Message -----
Probably RcppCLassic needs a version bump? It was last updated 1/26, before the Rcpp update.

Dan
Dirk Eddelbuettel
#
On 6 February 2014 at 10:49, Dan Tenenbaum wrote:
| The build system was pulling down a binary version of RcppClassic but it needs to be built from source.

*Every* package built against Rcpp needs to be rebuilt this time.

*Every* one.  See the release notes.
On 6 February 2014 at 11:28, Dan Tenenbaum wrote:
| Probably RcppCLassic needs a version bump? It was last updated 1/26, before the Rcpp update.

That *was* a pre-release built, but I didn't add (didn't need?)
importFrom(Rcpp, evalCpp). If it needs a fix we'll make a release, but it has
not yet been determined that it needs fix.

But *every* reverse dependency of Rcpp does not a rebuild this time.
We're sorry for the inconvenience but we were also very clear and upfront
about it.

Dirk
Dan Tenenbaum
# 
----- Original Message -----
If every reverse dependency of Rcpp needs a rebuild, and that includes RcppClassic, does it not follow that RcppClassic needs a rebuild on CRAN? Otherwise Mac or windows users without compilers are out of luck.

Dan
Dirk Eddelbuettel
#
On 6 February 2014 at 12:01, Dan Tenenbaum wrote:
| If every reverse dependency of Rcpp needs a rebuild, and that includes RcppClassic, does it not follow that RcppClassic needs a rebuild on CRAN? Otherwise Mac or windows users without compilers are out of luck.

It has always been my understanding that is what happens on Windows. 

But I work on Linux and I can assure you that you need to rebuild.

Greetings from Miami,  Dirk
Neumann, Steffen
# 
Hi,
On Thu, 2014-02-06 at 10:49 -0800, Dan Tenenbaum wrote:
...
Thanks Dan for fixing this.
On Thu, 2014-02-06 at 11:28 -0800, Dan Tenenbaum wrote:
...
Yours,
Steffen
Dan Tenenbaum
# 
----- Original Message -----
What do you mean by "that"?
I never doubted you on this. What I'm saying is that for people who rely on binary packages (mac and windows users without compilers installed), they too need the packages to be rebuilt against the new Rcpp, and RcppClassic has not been. My understanding of CRAN (which could be wrong, but this is how it works on Bioconductor) is that in the absence of a version bump, packages built during the daily builds do not propagate to the CRAN repositories. Therefore RcppClassic (and possibly other reverse dependencies of Rcpp) still need to be rebuilt, and cannot be used by Mac and Windows users unless they install from source and have the tools to do so, which defeats much of the purpose of having CRAN in the first place.

I would think that to be safe, every package that depends on Rcpp would have its version bumped. I did this on Bioconductor and am surprised it was not done on CRAN. 

Dan