[Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

[Dan Tenenbaum]

----- Original Message -----
> From: "Duncan Murdoch" <murdoch.duncan at gmail.com>
> Cc: r-devel at r-project.org
> Sent: Thursday, March 12, 2015 10:17:23 AM
> Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not	multilib)
> 
> I've just uploaded a minor update (3.3.0.1957) to Rtools33, adding
> the
> cygpath.exe utility.  That utility converts between Windows style
> paths
> like D:/Rtools and Cygwin style paths like /cygdrive/d/Rtools.   It
> may
> be useful in configuration files if your external library expects to
> find gcc on the path, since Rtools no longer puts it there.  Assuming
> you want to use the Rtools toolchain, you can construct the path to
> the
> gcc directory in your Makevars.win file as
> 
> $(cygpath $(RTOOLS))gcc492_$(WIN)/bin
> 
> (where RTOOLS and WIN are macros from RHOME/etc/*/Makeconf that
> should
> already have been read.)
> 

I had some problems with this. In the Bioconductor package zlibbioc, for example (which wraps zlib) there is a lower-level "Makefile.gcc" inside src/zlib-1.2.5/win32 which contains:

PREFIX =
ifeq "$(WIN)" "64"
CC = $(PREFIX)gcc -m64
else
CC = $(PREFIX)gcc -m32
endif


First of all, even though I have cygpath installed, using it as you suggest does not work, and does not seem to be necessary. Secondly, although $(WIN) is visible to the ifeq statement, it can't be expanded, that is to say, changing PREFIX to 

PREFIX = "$(RTOOLS)gcc492_$(WIN)/bin/"

doesn't work, and the error shows that gcc is being looked for in a path that ends with gcc492_/bin/ , in other words, the $(WIN) does not expand. However, changing to this:

ifeq "$(WIN)" "64"
PREFIX = "$(RTOOLS)gcc492_64/bin/"
CC = $(PREFIX)gcc -m64
else
PREFIX = "$(RTOOLS)gcc492_32/bin/"
CC = $(PREFIX)gcc -m32
endif

Works just fine. It's odd that the value of $(WIN) can be "seen" in order to correctly execute
the "ifeq", but it can't be expanded.

There are a number of fairly important packages in Bioconductor (and in CRAN too I imagine) that wrap C/C++ libraries and they all probably need some tweaking like this. I'm a little concerned that it's not such good practice to change third party code in this way, it makes maintenance just a little harder. It would be nice if maintainers could just add the latest version of the library to their packages without changing anything. But if making these changes is the only option, then so be it.

Dan



> Thanks to JJ Allaire for the prompting on this.
> 
> Duncan Murdoch
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>