Skip to content

R CMD check fails on Snow Leopard

8 messages · Simon Urbanek, Kasper Daniel Hansen, cstrato

#
Dear all,

Last week I have installed on my MacBook Pro Snow Leopard 10.6.3 and 
downloaded from Apple Xcode 3.2.2. Then I have installed R-2.11.0.pkg 
for Mac OS X 10.5 (Leopard) and higher.

Now I wanted to run R CMD check for my BioC package which contains C++ 
code but got the following error:

installing to /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared library 
'/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so':
   dlopen(/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so, 6): no 
suitable image found.  Did find:
	/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so: mach-o, but 
wrong architecture
ERROR: loading failed
* removing '/Volumes/CoreData/CRAN/xps.Rcheck/xps'

Do you have any hint what might be the reason for this error?
As far as I understand this message means that Snow Leopard is the wrong 
architecture, why?

Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n   S.t.r.a.t.o.w.a
V.i.e.n.n.a           A.u.s.t.r.i.a
e.m.a.i.l:        cstrato at aon.at
_._._._._._._._._._._._._._._._._._
#
On Apr 28, 2010, at 5:22 PM, cstrato wrote:

            
Apparently the R and your package have different architectures. The reason is most likely your package - often badly written Makevars or Makefile if some dependencies are used, or stale object files in the sources (failure to clean up) etc. You'd have to show us the package and exactly how you're trying to instal it if we are to help you further.
You understand the message incorrectly - it tells you the R (which is the one loading the package) cannot find binary of the same architecture in the package, but it can find another, different, architecture instead. "Snow Leopard" is not an architecture it's an operating system.

Cheers,
Simon
#
Dear Simon,

My package is "xps" which has always worked on Tiger and also on 
Leopard, thus I am shocked that it does not work on Snow Leopard. The 
problem is not only that I cannot do "R32 CMD check xps-1.9.0.tar.gz" 
which results in the error message mentioned, but that the binary which 
I have downloaded using "biocLite("xps")" gives me the same error message.

When I start "R32" which I need to do since I have compiled the ROOT 
framework for 32 bit, I get:

 > library(xps)
Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared library 
'/Users/rabbitus/Library/R/2.11/library/xps/libs/i386/xps.so':
   dlopen(/Users/rabbitus/Library/R/2.11/library/xps/libs/i386/xps.so, 
6): Library not loaded: @rpath/libCore.so
   Referenced from: 
/Users/rabbitus/Library/R/2.11/library/xps/libs/i386/xps.so
   Reason: no suitable image found.  Did find:
         /Volumes/CoreData/ROOT/root/lib/libCore.so: mach-o, but wrong 
architecture
         /Volumes/CoreData/ROOT/root/lib/libCore.so: mach-o, but wrong 
architecture
Error: package/namespace load failed for 'xps'

At the moment I have no idea what might be the reason for this:-(

Best regards
Christian
On 4/28/10 11:38 PM, Simon Urbanek wrote:
#
You can have a look at the library by doing file (otool is also nice
to know btw), I get

# file affxparser.so
affxparser.so: Mach-O 64-bit dynamically linked shared library x86_64

You do this on both the ROOT library and the xps.so library to see
what the architectures are.  Based on the error message, they are
different.  Why, is something I think you will have to track down
yourself, because that depends on how you compiled R/ROOT.

Kasper
On Wed, Apr 28, 2010 at 5:54 PM, cstrato <cstrato at aon.at> wrote:
#
Dear Kasper,

Thank you for this suggestion which was very helpful.

As it turns out, at the moment I am not able to compile ROOT for 32 bit 
on Snow Leopard. I have already contacted the ROOT developers.

Best regards
Christian
On 4/29/10 5:25 AM, Kasper Daniel Hansen wrote:
1 day later
#
Dear Simon, dear Kasper,

While I could solve the problem with wrong architecture, R CMD check now 
results in the following error:

installing to /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared library 
'/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so':
   dlopen(/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so, 6): 
Symbol not found: __ZN10TCanvasImp11ShowMembersER16TMemberInspectorPc
   Referenced from: /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so
   Expected in: flat namespace
  in /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so
ERROR: loading failed
* removing '/Volumes/CoreData/CRAN/xps.Rcheck/xps'


This time I get this error both on Leopard for "i386" and on Snow 
Leopard for "x86_64" while the Bioconductor server does not have this 
problem (to my great relieve), see:
http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/pelham-checksrc.html

Do you have any idea what might be the reason for this problem?

Best regards
Christian
On 4/29/10 5:25 AM, Kasper Daniel Hansen wrote:
#
On Apr 30, 2010, at 4:55 PM, cstrato wrote:

            
Likely xps was not linked against all necessary libraries. Since it is sinked as dynamic library bugs like that are only visible at run-time not at link-time.

Cheers,
Simon
#
Dear Simon,

Thank you for your reply. The difference between the code uploaded to 
BioC and my new code is the "Makefile.arch".

I have just run R CMD check using the uploaded "Makefile.arch" where the 
relevant part is:

ifeq ($(ARCH),macosx)
# MacOS X with cc (GNU cc 2.95.2 and gcc 3.3)
MACOSX_MINOR := $(shell sw_vers | sed -n 's/ProductVersion://p' | cut -d 
. -f 2)
MACOSXTARGET := MACOSX_DEPLOYMENT_TARGET=10.$(MACOSX_MINOR)
ifeq ($(MACOSX_MINOR),5)
MACOSX_MINOR  = 4
endif
CXX           = c++
CXXFLAGS      = $(OPT2) -pipe -Wall -W -Woverloaded-virtual
LD            = $(MACOSXTARGET) c++
LDFLAGS       = $(OPT2) -bind_at_load
# The SOFLAGS will be used to create the .dylib,
# the .so will be created separately
DllSuf        = dylib
UNDEFOPT      = dynamic_lookup
ifneq ($(MACOSX_MINOR),4)
ifneq ($(MACOSX_MINOR),3)
UNDEFOPT      = suppress
LD            = c++
endif
endif
SOFLAGS       = -dynamiclib -single_module -undefined $(UNDEFOPT)
endif

Using this code I can once again run R CMD check w/o problems, however, 
since this code does not work on Snow Leopard, I have replaced it with 
the following code which causes the reported error:

ifeq ($(ARCH),macosx)
# MacOS X with cc (GNU cc 2.95.2 and gcc 3.3)
MACOSX_MINOR := $(shell sw_vers | sed -n 's/ProductVersion://p' | cut -d 
. -f 2)
ifeq ($(MACOSX_DEPLOYMENT_TARGET),)
MACOSXTARGET := MACOSX_DEPLOYMENT_TARGET=10.$(MACOSX_MINOR)
else
MACOSXTARGET := MACOSX_DEPLOYMENT_TARGET=$(MACOSX_DEPLOYMENT_TARGET)
endif
CXX           = g++
CXXFLAGS      = $(OPT2) -pipe -Wall -W -Woverloaded-virtual
LD            = $(MACOSXTARGET) g++
LDFLAGS       = $(OPT2)
# The SOFLAGS will be used to create the .dylib,
# the .so will be created separately
ifeq ($(subst $(MACOSX_MINOR),,1234),1234)
DllSuf        = so
else
DllSuf        = dylib
endif
UNDEFOPT      = dynamic_lookup
ifneq ($(subst $(MACOSX_MINOR),,12),12)
UNDEFOPT      = suppress
LD            = g++
endif
SOFLAGS       = -dynamiclib -single_module -undefined $(UNDEFOPT) 
-install_name $(CURDIR)/
endif

Do you have any hint why this code does not work?

Best regards
Christian
On 4/30/10 11:00 PM, Simon Urbanek wrote: