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<cstr...@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@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
