g++-4.6.real: error: unrecognized option '-R' - c

Question

I am trying to compile phpcompiler from source using this configure command.
./configure --prefix=/opt/phc-0.3.0.1/ --with-php=/opt/php-5.3.17/
The configure error was,
checking for exit in -lboost_regex-mt... no
checking for exit in -lboost_regex-mt... (cached) no
checking for exit in -lboost_regex... no
checking for exit in -lboost_regex... (cached) no
checking for exit in -lboost_regex... (cached) no
configure: error: Could not link against boost_regex
Thats completely wrong as I have both boost and boost_regex packages installed. Both libs and header files. Then I dug this in the config.log file
configure:17053: g++ -o conftest -g -O2 -L/lib/php5 -L/usr/lib/php5 conftest.cpp /usr/lib/libCrun.so.1 -lphp5 -L/opt/php-5.3.17//lib -R/opt/php-5.3.17//lib -ldl >&5
g++-4.6.real: error: /usr/lib/libCrun.so.1: No such file or directory
g++-4.6.real: error: unrecognized option '-R'
So, for this unrecognized option '-R' error, many -lboost_regex checks were failed!
How can I fix this? is there any file that I can edit to fix it? And why -R is used? I think it would be -L flag.

Answer 1

As your comment indicates that this -R option comes from configure, the following line in m4/php-embed.m4 appears to be the most likely source:
LIBS="-lphp5 -L${PHP_INSTALL_PATH}/lib -R${PHP_INSTALL_PATH}/lib $LIBS"
If you look at configure, all other occurrences of -R will write that as ${wl}-R, where ${wl} will most likely expand to -Wl,. So one way to fix this would be adding the ${wl} before -R in the above line and running autogen.sh to recreate configure.
You may whish to file a bug for this, after checking existing ones.

Answer 2

You can see a similar error (and resolution) in Git 2.23 (Q2 2019) where -R has been removed.
The way of specifying the path to find dynamic libraries at runtime
has been simplified.
The old default to pass -R/path/to/dir has been replaced with the new default to pass -Wl,-rpath,/path/to/dir, which is the more recent GCC uses.
See commit 0f50c8e (17 May 2019) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 51d6c0f, 13 Jun 2019)
Makefile: remove the NO_R_TO_GCC_LINKER flag
Change our default CC_LD_DYNPATH invocation to something GCC likes
these days.
Since the GCC 4.6 release unknown flags haven't been passed through to ld(1). Thus our previous default of CC_LD_DYNPATH=-R would cause an error on modern GCC unless NO_R_TO_GCC_LINKER was set.
Our use of "-R" dates back to 455a7f3 ("More portability.",
2005-09-30, Git v0.99.8a).
Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27, Git v1.5.0-rc1) the NO_R_TO_GCC flag was added, allowing optional use of "-Wl,-rpath=".
Then in f5b904d ("Makefile: Allow CC_LD_DYNPATH to be overriden",
2008-08-16, Git v1.6.1-rc1) the ability to override this flag to something else
entirely was added, as some linkers use neither "-Wl,-rpath," nor "-R".
From what I can tell we should, with the benefit of hindsight, have
made this change back in 2006.
GCC & ld supported this type of invocation back then, or since at least binutils-gdb.git's.
a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20).
Further reading and prior art can be found at:
tsuna/boost.m4 issue 15
Gnome issue 641416
Building cURL passing the -R option to linker
Making a plain "-R" an error seems from reading those reports to have been
introduced in GCC 4.6 released on March 25, 2011, but I couldn't
confirm this with absolute certainty, its release notes are ambiguous
on the subject, and I couldn't be bothered to try to build & bisect it
against GCC 4.5.