[R-SIG-Mac] [Bioc-devel] how to create my own repository of mac os x binaries?
simon.urbanek at r-project.org
Tue May 16 16:18:27 CEST 2006
[I'm CCing this to SIG-Mac as this may be of global interest]
On May 16, 2006, at 9:25 AM, Seth Falcon wrote:
> stefano iacus <stefano.iacus at unimi.it> writes:
>> Please, take care that the new R binary for OS X is Universal,
>> which means you have to consider also a universal build of the
> Two questions about this:
> Is it possible to create Universal binaries on the PPC-based macs?
Out-of-the-box, no. Theoretically, yes. Practically, possibly
The only problem (AFAICS) is that Tiger installed on PPC machines
doesn't contain Intel system libraries. Although the gcc we are
providing can compile i686 binaries on ppc machines, the final
linking step fails, because the system libraries are missing. So the
solution could be to add i686 system libraries to ppc Tiger.
The 'official' way to do it is to use Xcode 10.4u SDK, but R is not
aware of this concept which is local to Xcode. (Idea: lipo the i686
system libraries from the SDK to the system)
> Won't CRAN-style repositories continue to support separate
> locations for ppc and intel OSX packages?
Sort of. Although you could do that, it doesn't make much sense,
because if you had separate binary packages, you may as well create
the universal one by copying their contents into one directory.
However, CRAN R is universal, so you cannot offer different kind of
packages. This is how it works in detail:
- requests file from the current architecture's directory (e.g. ppc)
Repository (convention used by CRAN, but not enforced in any way):
- all universal packages are in `architecture' directory "universal"
- "ppc" and "i686" point symlinks to "universal"
Universal packages are tagged as "Built: universal-apple-darwinXXX"
Since even the universal R is looking for arch-specific packages, you
cannot have two different builds of R (this was never supposed to
work). You can, however, opt to create package for the universal R
that contains binary for only one architecture. You could put this
binary in the corresponding 'ppc' or 'i686' tree. In that case it
will appear only on the appropriate architecture.
> If so, creating universal binaries seems a convenience for the
> package producer rather than end users.
It depends - "universal" R has the property that it works as-is on
either platform. Single-arch packages don't, so if you're using the
same image or hd to boot different machines, only universal package
will work. Therefore and given the fact that if you have package for
each arch, you effectively have the universal binary, you're
discouraged to create individual packages.
> We are finding some difficulties in building universal binaries for
> packages that depend upon external libraries and it isn't clear to
> me that it won't be easier to build ppc and intel packages
> separately (assuming one has access to both types of systems).
You can, of course, do that and create the universal package.
Universal package is effectively nothing else but
R_ARCH=/i686 build foo for i686 in i686/foo
R_ARCH=/ppc build foo for ppc in ppc/foo
cp -r ppc/foo/libs/ppc i686/foo/libs/
pack foo in i686 and you have universal package
I doesn't matter whether you do that on a single machine or you use
two. (Well-kept secret: universal R is built this way in order to be
able to run make check natively. However, the packages are not).
As of external libraries - it's (mostly) not a problem, either,
because you can simply lipo them together, even if you build them on
More information about the R-SIG-Mac