Hi,
A user reported to me that the latest binary build of Matching (2.1-1,
built May 29) for R-2.3.0 does not load on his Intel Mac. And after
some debugging, I ended up rediscovering a version of the issue which
Douglas Bates posted regarding the beta test build of R-2.3.1.
The problem is that the Intel OS X Matching library posted on CRAN
assumes that the libgcc_s.1.0.dylib library is located in
/usr/local/gcc4.0/i686-apple-darwin8/lib/ which is not where it is
installed by the default gcc package. This problem does not occur
when I build Matching on my Intel Mac.
The following fixes the problem (the same fix as Doug pointed out):
cd /usr/local/gcc4.0
sudo mkdir i686-apple-darwin8
cd i686-apple-darwin8
sudo ln -s ../lib
Otherwise, one gets the following error:
library(Matching)
Loading required package: MASS
Loading required package: rgenoud
Error in dyn.load(x, as.logical(local), as.logical(now)) :
unable to load shared library
'/Library/Frameworks/R.framework/Resources/library/Matching/libs/i386/\
Matching.so':
dlopen(/Library/Frameworks/R.framework/Resources/library/Matching/libs/i386/Matching.so, 6): Library not l\
oaded: /usr/local/gcc4.0/i686-apple-darwin8/lib/libgcc_s.1.0.dylib
Referenced from:
/Library/Frameworks/R.framework/Resources/library/Matching/libs/i386/Matching.so
Reason: image not found
Error: package/namespace load failed for 'Matching'
Cheers,
Jas.
=======================================
Jasjeet S. Sekhon
Associate Professor
Travers Department of Political Science
Survey Research Center
UC Berkeley
http://sekhon.berkeley.edu/
V: 510-642-9974 F: 617-507-5524
On May 29, 2006, at 6:32 PM, Jasjeet Singh Sekhon wrote:
A user reported to me that the latest binary build of Matching
(2.1-1, built May 29) for R-2.3.0 does not load on his Intel Mac.
Your package bypasses the shlib building process and does not even
link to libR. The fix-up code doesn't expect anything like that,
because the consequence is that the `.so's don't contain the path to
R and hence it is not possible to determine the correct path for the
libraries (stdc++, gcc_s) that come shipped with R from the so itself.
Your package is the only one on CRAN with this issue. Although the
behavior is legal, I would recommend rather using Makevars
instead ;). For now I have fixed it manually and I'll see if I can
get around the problem.
Cheers,
Simon
Simon,
Thanks. If linking to libR would solve the issue, I can easily do
that. Let me know. If not, I guess I'll use Makevars for OS X.
However, there are two reasons why I don't currently use Makevars but
a legal Makefile generated by a configure script. First, I don't want
to compile all of the files on all platform (for example, malloc.c is
only for OS X but OS X does not need a cblas wrapper). Second, I want
to override the default CXXFLAGS and not simply prepend arguments to
it via PKG_CXXFLAGS. For this package, aggressive optimization flags
are both safe and make a big difference. Is it safe to assume that
all version of gcc will follow the first flag directive when
contradictory flags are given? For example, if both -O3 and -O2 are
entered? The Portland Group Compiler follows the last argument (-O2
in this case). I guess this problem can be avoided for the default
install (which uses the "-g -O2" flags) by prepending the additional
optimizations implied by -O3. That's what I do on Windows right now
(via Makevars.win).
Given the forgoing, creating my own Makefile by a configure script was
the easiest and most flexible thing to do. I can easily get the
configure script to generate a Makevars file instead and get the
script to move source files around so everything remaining in the src
directory actually needs to be compiled on a given platform. This
will cause R CMD check to complain about non portable compilation
flags in Makevars even though there is a configure script checking the
compiler. But I assume that is a minor issue since you and Kurt could
ignore that warning for this package when posting to CRAN?
Cheers,
Jas.
=======================================
Jasjeet S. Sekhon
Associate Professor
Travers Department of Political Science
Survey Research Center
UC Berkeley
http://sekhon.berkeley.edu/
V: 510-642-9974 F: 617-507-5524
=======================================
Simon Urbanek writes:
> Jas,
>
> thanks for the report.
>
> On May 29, 2006, at 6:32 PM, Jasjeet Singh Sekhon wrote:
>
> > A user reported to me that the latest binary build of Matching
> > (2.1-1, built May 29) for R-2.3.0 does not load on his Intel Mac.
>
> Your package bypasses the shlib building process and does not even
> link to libR. The fix-up code doesn't expect anything like that,
> because the consequence is that the `.so's don't contain the path to
> R and hence it is not possible to determine the correct path for the
> libraries (stdc++, gcc_s) that come shipped with R from the so itself.
>
> Your package is the only one on CRAN with this issue. Although the
> behavior is legal, I would recommend rather using Makevars
> instead ;). For now I have fixed it manually and I'll see if I can
> get around the problem.
>
> Cheers,
> Simon