-R does not seem to be an option for g++ or gcc anywhere. -R may be a linker option on some platforms that is equivalent of -rpath to gnu ld, ... This seems to be a known bug in boost builds ... have a look at Use -Wl to pass arguments to the linker.

It actually has the patch available there

I am re-posting it for convenience, however PLEASE PLEASE look at the original URL linked above for official patch!

--- ../gnote/m4/boost.m4    2011-01-25 14:30:18.000000000 +0200
+++ m4/boost.m4 2011-02-27 20:57:11.686221539 +0200
@@ -403,7 +403,7 @@
       LDFLAGS=$boost_save_LDFLAGS
       LIBS=$boost_save_LIBS
       if test x"$Boost_lib" = xyes; then
-        Boost_lib_LDFLAGS="-L$boost_ldpath -R$boost_ldpath"
+        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-R$boost_ldpath"
         Boost_lib_LDPATH="$boost_ldpath"
         break 6
       else

I had a similar problem trying to install mvtnorm in R on Ubuntu. I was getting the error:

gcc: error: unrecognized command line option "-fstack-protector-strong"

I looked into which version of gcc was being used by default

which gcc
/home/ralien/anaconda3/bin/gcc

It turns out that, for some reason, Anaconda uses a gcc, g++, and gfortran compiler that is really old: version 4.8.5. This version doesn't seem to support the -fstack-protector-strong argument.

I checked the gcc, g++, and gfortran version in /usr/bin and saw that my system compilers were much newer, 5.4 or so. The trick is to force R to use the new compilers by creating

~/.R/Makevars

and changing the path for ALL compilers to the system version. So the Makevars file would contain the entries:

CC=/usr/bin/gcc
CXX=/usr/bin/g++
FC=/usr/bin/gfortran
F77=/usr/bin/gfortran

You can then use R CMD INSTALL to compile the package with the new version of gcc, g++, and gfortran.

Or at least this worked for me.

This is not that well documented (e.g. I failed to locate it in either 'R Extension' or 'R Admin' right now) but Brian Ripley mentioned it a few times on the lists.

Basically, at R compile time, settings are registered and the stored in $R_HOME/etc/Makeconf. One possibility is to edit that file directly, but you may not have root privileges or may not want to affect all other users. So the better may be to create

~/.R/Makevars

with entries

CC=gcc-4.4
CXX=g++-4.4

plus whichever optmisation flags etc you want to set. That will the affect all subsequent uses of R CMD INSTALL or R CMD check or ... that you run.

Other files in $R_HOME/etc/ can similarly be overridden locally from ~/.R/.

For GCC, this is just one option, not two:

-Wl,-R`pwd` 

The -Wl,<something> construct is used to pass the <something> part as option(s) to the linker (ld). In this case, it tells gcc to invoke ld as:

ld -R`pwd` <other parameters...>

And if you look at man ld in Linux, you'll find (emphasis mine):

-R filename

[...]

Read symbol names and their addresses from filename, but do not relocate it or include it in the output. This allows your output file to refer symbolically to absolute locations of memory defined in other programs. You may use this option more than once.

For compatibility with other ELF linkers, if the -R option is followed by a directory name, rather than a file name, it is treated as the -rpath option.

And the -rpath option is:

-rpath=dir

Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. [...]

So the entire construct means "tell the runtime linker to search shared objects for linking in the current working directory".

The ld man page also notes:

The -rpath option may also be used on SunOS. By default, on SunOS, the linker will form a runtime search path out of all the -L options it is given. If a -rpath option is used, the runtime search path will be formed exclusively using the -rpath options, ignoring the -L options. This can be useful when using gcc, which adds many -L options which may be on NFS mounted file systems.

So, the overall goal for this option construct in e.g.

cc -g -c -o main.o main.c
cc -g -fpic -c -o power_slow.po power_slow.c
cc -shared -fpic -o libpowerslow.so power_slow.po
cc  main.o -L`pwd` -Wl,-R`pwd` -lpowerslow -o main

is to ensure the resulting main binary will search for libpowerslow.so only in the current working directory, so it will pick the exact version compiled by the third command, and not any other version of libpowerslow.so that might exist elsewhere on the system.

You should realize that while "baking in" the current working directory is useful with short-lived example binaries like the one built here, you should specify something else as the runtime library search path when building something to be installed for system-wide use.