[Rd] distributable binary Mac packages [Was: libgfortran misplaced in Mac OS X R install]
Simon Urbanek
simon.urbanek at r-project.org
Thu Mar 4 21:11:23 CET 2010
On Mar 4, 2010, at 14:44 , Prof Brian Ripley wrote:
> Another possibility is to link statically to libgfortran. That has
> pros and cons, but for libgfortran not many cons apart from space
> for multiple copies in sundry packages (and is what is done on
> Windows, BTW).
>
> There are several ways to arrange that. As far as I recall I
> temporarily removed /usr/local/lib/libgfortran*.dylib: another way
> is to edit FLIBS in Makeconf (but then you do need to know which
> copies of that file you need to edit).
>
The Xcode add-on compilers from R.research.att.com use static
libgfortran by default, so if you didn't install any other Fortran,
that will be the default.
However, there are issues when linking multiple modules that also link
libgfortran statically - dylibs are not allowed to contain multiple
common symbols on OS X (with flat namespaces) which is the case if you
get static libgfortran from two sources independently. The most
prominent example is libRlapack linked into a package that also uses
Fortran (that's why CRAN Rlapack does not use static libgfortran).
There are ways around, but it all makes the already complex issue even
more complex ;).
> As far as I know we don't document in the standard manuals how to
> build distributable binary Mac packages, and perhaps we should do so
> in due course (or at least point at where the information can be
> found).
>
Yes, I agree. There are bits and pieces in the R for Mac FAQ, but it
may be worth putting what I wrote below into the FAQ.
Thanks,
Simon
> On Thu, 4 Mar 2010, Simon Urbanek wrote:
>
>> Hi Michael,
>>
>> On Mar 3, 2010, at 12:01 , Michael Spiegel wrote:
>>
>>> I am the guy who compiles the OpenMx binaries. We would be
>>> delighted to place our package on CRAN, once the project is stable
>>> enough so that we are comfortable releasing it to the larger
>>> public. Let's try to track down where I made a mistake. Our
>>> Makevars.in file contains the line:
>>> PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS)
>>> In addition, on the build machine I noticed that a copy of
>>> libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode
>>> install placed a copy of it there.
>>
>> No, it is part of the GNU Fortran installation. Anything you
>> compile with a Fortran requires that you have that Fortran
>> installed at run time, because Fortran uses its own run-time
>> libraries (if the Fortran you compiled with used dynamic
>> libraries). This implies that if you distribute your package you
>> have to tell users to install the same Fortran you used to compile
>> it.
>>
>> However, unlike other unices Mac users don't necessarily have
>> development tools installed, so on CRAN we make an effort to modify
>> the binaries such that they work even without the tools they have
>> been compiled with. There are several possible approaches, but
>> since R itself already uses the same Fortran, we ship a copy of the
>> Fortran libraries inside R and modify packages such that they use
>> it instead of the one from dev tools (see below for details).
>>
>>
>>> To create the binary release, I run R CMD INSTALL --build.
>>
>> That is not sufficient to create a binary of your package, because
>> it contains a configure script (this is unrelated to the above -
>> see R-admin 2.6). What you want to use is something like this
>> (assuming R 2.10.1 Leopard build and Fortran from CRAN):
>>
>> R --arch=i386 CMD INSTALL OpenMx_0.2.9-1147.tar.gz
>> R --arch=x86_64 CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz
>> R --arch=ppc CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz
>> cd /Library/Frameworks/R.framework/Versions/2.10/Resources/library
>>
>> # fix the Fortran paths to point to R 2.10 instead
>> for lib in `ls OpenMx/libs/*/*.so`; do
>> install_name_tool -change /usr/local/lib/libgfortran.2.dylib \
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libgfortran.2.dylib \
>> $lib
>> done
>>
>> # change permissions for distribution
>> sudo chown -Rh root:admin OpenMx
>> sudo chmod -R g+w OpenMx
>>
>> # pack it up
>> tar fvcz ~/OpenMx_0.2.9-1147.tgz OpenMx
>>
>>
>> You can check that you have the correct paths using otool -L:
>>
>> ginaz:library$ otool -L OpenMx/libs/*/*.so
>> OpenMx/libs/i386/OpenMx.so:
>> OpenMx.so (compatibility version 0.0.0, current version 0.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libgfortran.2.dylib (compatibility version 3.0.0, current version
>> 3.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libRlapack.dylib (compatibility version 2.10.0, current version
>> 2.10.1)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libR.dylib (compatibility version 2.10.0, current version 2.10.1)
>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
>> CoreFoundation (compatibility version 150.0.0, current version
>> 476.19.0)
>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 111.1.4)
>> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
>> (compatibility version 1.0.0, current version 242.0.0)
>> OpenMx/libs/ppc/OpenMx.so:
>> OpenMx.so (compatibility version 0.0.0, current version 0.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libgfortran.2.dylib (compatibility version 3.0.0, current version
>> 3.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libRlapack.dylib (compatibility version 2.10.0, current version
>> 2.10.1)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libR.dylib (compatibility version 2.10.0, current version 2.10.1)
>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
>> CoreFoundation (compatibility version 150.0.0, current version
>> 476.19.0)
>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 111.1.4)
>> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
>> (compatibility version 1.0.0, current version 242.0.0)
>> OpenMx/libs/x86_64/OpenMx.so:
>> OpenMx.so (compatibility version 0.0.0, current version 0.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libgfortran.2.dylib (compatibility version 3.0.0, current version
>> 3.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libRlapack.dylib (compatibility version 2.10.0, current version
>> 2.10.1)
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libR.dylib (compatibility version 2.10.0, current version 2.10.1)
>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
>> CoreFoundation (compatibility version 150.0.0, current version
>> 476.19.0)
>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
>> version 1.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 111.1.4)
>> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
>> (compatibility version 1.0.0, current version 242.0.0)
>>
>>
>> If you are dealing with only one R version, you can change the ID
>> of your Fortran library instead of touching the package files:
>>
>> install_name_tool -id \
>> /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/
>> libgfortran.2.dylib
>> /usr/local/lib/libgfortran.2.0.0.dylib
>>
>> Note, however, that this will lead to (possibly silent) errors if
>> you forget to change it when switching to another R version, so I
>> prefer to fix the package instead.
>>
>> Cheers,
>> Simon
>>
>>
>>> The beta test users install the package using the following
>>> script: http://openmx.psyc.virginia.edu/getOpenMx.R.
>>
>>
>>
>>> On Wed, Mar 3, 2010 at 9:48 AM, Tim Brick <tbrick at virginia.edu>
>>> wrote:
>>>>> From: Simon Urbanek <simon.urbanek at r-project.org>
>>>>> Date: March 3, 2010 8:32:52 AM MST
>>>>> To: tbrick at virginia.edu
>>>>> Cc: r-devel at stat.math.ethz.ch, R-bugs at r-project.org
>>>>> Subject: Re: [Rd] libgfortran misplaced in Mac OS X R install
>>>>> (PR#14226)
>>>>> This is not an R bug so please don't abuse R-bugs. It is likely
>>>>> a bug in the way OpenMx binaries are distributed by someone (you
>>>>> didn't even say where you got them from) - OpenMx is not even on
>>>>> CRAN so take that to whoever gave you the binaries. On CRAN we
>>>>> use the correct paths.
>>>>> Cheers,
>>>>> Simon
>>>>> On Mar 2, 2010, at 11:45 , tbrick at virginia.edu wrote:
>>>>>> Full_Name: Timothy Brick
>>>>>> Version: 2.10
>>>>>> OS: Mac OS X (seen on both 10.6 and 10.5)
>>>>>> Submission from: (NULL) (63.255.24.5)
>>>>>> When using install.packages in R on Mac OS X, packages that
>>>>>> require gfortran
>>>>>> throws an error (Example below from installation of OpenMx
>>>>>> package):
>>>>>> Loading required package: OpenMx
>>>>>> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>>>>>> unable to load shared library
>>>>>> '/Library/Frameworks/R.framework/Resources/library/OpenMx/libs/
>>>>>> i386/OpenMx.so':
>>>>>> dlopen(/Library/Frameworks/R.framework/Resources/library/OpenMx/
>>>>>> libs/i386/OpenMx.so,
>>>>>> 6): Library not loaded: /usr/local/lib/libgfortran.2.dylib
>>>>>> Referenced from: /Library/Frameworks/R.framework/Resources/
>>>>>> library/OpenMx/libs/i386/OpenMx.so
>>>>>> Reason: image not found
>>>>>> libgfortran.2.dylib does exist, but in
>>>>>> /Library/Frameworks/R.framework/Versions/2.10/Resouces/lib/
>>>>>> libgfortran.2.dylib
>>>>>> (or /2.9/, depending on version installed).
>>>>>> A workaround at present involves creating a symbolic link from
>>>>>> the above file to
>>>>>> /usr/local/lib/libgfortran.2.dylib, however this requires sudo
>>>>>> access and is
>>>>>> confusing for novice users.
>>>>>> There is more discussion of this bug as it relates to OpenMx at:
>>>>>> http://openmx.psyc.virginia.edu/thread/316
>>>>>> Posts on other forums indicate a similar issue with other
>>>>>> packages including
>>>>>> vegan and lme4:
>>>>>> http://r-forge.r-project.org/forum/forum.php?thread_id=728&forum_id=194
>>>>>> https://stat.ethz.ch/pipermail/r-sig-mac/2009-May/006210.html
>>>>> Those are very old posts and those were temporary issues in the
>>>>> CRAN build system that have been promptly resolved.
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Brian D. Ripley, ripley at stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
>
More information about the R-devel
mailing list