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

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.