Simon Urbanek wrote: <snipped> > > In fact, there is even one more caveat which I don't remember seeing > mentioned - it *must* be a build without r_arch set, otherwise the > cross-build fails as well (despite a correct version). I got bitten by > this recently when trying to use the OS X binary for cross-building..
I developed my own multi-arch set up during 2.3.x before the official implementation - I have a "massaged" rpm spec file which, depends on whether one does 'rpmbuild --target=i686 R.spec' or just 'rpmbuild R.spec' (='rpmbuild --target=x86_64 R.spec'), prepend -m32 to CFLAGS/FFLAGS/LDFLAGS, switch %_lib between lib or lib64, and also rename /usr/bin/R to /usr/bin/R64 . So my 32-bit R and 64-bit R are essentially separate: /usr/bin/R + /usr/lib/R for 32-bit, /usr/bin/R64 + /usr/lib64/R for 64-bit, and they only share the docs directories such as /usr/share/info and /usr/share/doc/R-* . I read that the new r_arch based set-up is more space efficient, but I haven't switch over yet (and not in any great urgency, since my current bi-arch set up does what I want). > And while we are at cross-building, it is possible to generate chm > manuals via hhc through wine, but you have to use original itss.dll > instead of the one supplied by wine. The hhw path in MkRules must then > point to the local directory on the host (because it's used for the > headers files) and you'll have to create shell-wrapper for hhc that > looks somewhat like "wine hhc.exe $*". Thanks for that tip - I'll be sure to try it out the next time I cross-build. Are you using wine under OS X intel or did we switch platform in two paragraphs? Just for curiosity. Hin-Tak ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
