[R-SIG-Mac] R CMD check fails on Snow Leopard
cstrato
cstrato at aon.at
Fri Apr 30 23:30:28 CEST 2010
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:
>
> On Apr 30, 2010, at 4:55 PM, cstrato wrote:
>
>> 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?
>>
>
> 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
>
>>
>> On 4/29/10 5:25 AM, Kasper Daniel Hansen 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 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:
>>>>>
>>>>> On Apr 28, 2010, at 5:22 PM, cstrato wrote:
>>>>>
>>>>>> 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?
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>> As far as I understand this message means that Snow Leopard is the wrong
>>>>>> architecture, why?
>>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> R-SIG-Mac at stat.math.ethz.ch
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>
>>
>>
>
>
More information about the R-SIG-Mac
mailing list