Use -Wl,-R instead of -R #15
Comments
|
How come GCC 4.6 no longer supports |
|
I think -R is linker option, not GCC. I think in this case this statement from release notes applies: |
|
Use -Wl to pass arguments to the linker. This is more correct than giving -R directly to GCC. Actually, GCC 4.6 |
|
Unfortunately, for some reason, -Wl,-R instead of -R apparently fails for MacOS X gcc 4.2.1 (which, as I was told, is the latest Apple offers). Anyone with an insight into MacOS X gcc here, perchance? |
|
Okay, dug around a bit with the friend with a Mac that told me of the issues in the first place, and apparently, MacOS X's ld doesn't know -R. It does work when passing "-Wl,-rpath $boost_ldpath" (note the space, MacOS X's ld doesn't like a "=" there either) to gcc, though. |
|
Seems like we need a separate test to find whether the compiler/linker support |
|
Sure: #19 |
riccardomurri
pushed a commit
to riccardomurri/boost.m4
that referenced
this issue
Jul 23, 2011
This is more correct than giving -R directly to GCC. Actually, GCC 4.6 doesn't seem to like -R at all. Closes tsuna#15.
Closed
akimd
pushed a commit
to akimd/boost.m4
that referenced
this issue
Nov 26, 2014
This is more correct than giving -R directly to GCC. Actually, GCC 4.6 doesn't seem to like -R at all. Closes tsuna#15.
avar
added a commit
to avar/git
that referenced
this issue
May 16, 2019
Remove the NO_R_TO_GCC_LINKER flag, thus switching the default to "-Wl,-rpath,$LIBPATH" instead of our current "-R$LIBPATH". This is a relatively obscure thing that only kicks in when using one of the LIBDIR flags, e.g. LIBPCREDIR or CURLDIR. How we invoke the linker to do this can still be overridden with CC_LD_DYNPATH, as seen in our configure.ac script. Our use of "-R" dates back to 455a7f3 ("More portability.", 2005-09-30). Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27) 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) 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[1] a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20). Most people compiling git with a custom LIBDIR are going to be on a GNU-ish system, and having to provide this NO_R_TO_GCC_LINKER flag on top of a custom LIBDIR is annoying. There are some OS's that don't support -rpath, e.g. AIX ld just supports "-R". Perhaps we should follow this up with some config.mak.uname changes, but as noted it's quite possible that nobody on these platforms uses this (instead libraries in the system's search path). We *could* also use "-Wl,-R", but let's not introduce something new. Further reading and prior art can be found at [2][3][4][5]. 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. 1. git://sourceware.org/git/binutils-gdb.git 2. tsuna/boost.m4#15 3. https://bugzilla.gnome.org/show_bug.cgi?id=641416 4. https://stackoverflow.com/questions/12629042/g-4-6-real-error-unrecognized-option-r 5. https://curl.haxx.se/mail/archive-2014-11/0005.html 6. https://gcc.gnu.org/gcc-4.6/changes.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
avar
added a commit
to avar/git
that referenced
this issue
May 17, 2019
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. This CC_LD_DYNPATH flag is really obscure, and I don't expect anyone except those working on git development ever use this. It's not needed to simply link to libraries like say libpcre, but *only* for those cases where we're linking to such a library not present in the OS's library directories. See e.g. ldconfig(8) on Linux for more details. I use this to compile my git with a LIBPCREDIR=$HOME/g/pcre2/inst as I'm building that from source, but someone maintaining an OS package is almost certainly not going to use this. They're just going to set USE_LIBPCRE=YesPlease after installing the libpcre dependency, which'll point to OS libraries which ld(1) will find without the help of CC_LD_DYNPATH. Another thing that helps mitigate any potential breakage is that we detect the right type of invocation in configure.ac, which e.g. HP/UX uses[1], as does IBM's AIX package[2]. From what I can tell both AIX and Solaris packagers are building git with GCC, so I'm not adding a corresponding config.mak.uname default to cater to their OS-native linkers. Now for an overview of past development in this area: Our use of "-R" dates back to 455a7f3 ("More portability.", 2005-09-30). Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27) 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) 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[3] a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20). Further reading and prior art can be found at [4][5][6][7]. Making a plain "-R" an error seems from reading those reports to have been introduced in GCC 4.6 released on March 25, 2011[8], 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. 1. https://public-inbox.org/git/20190516093412.14795-1-avarab@gmail.com/ 2. https://www.ibm.com/developerworks/aix/library/aix-toolbox/alpha.html 3. git://sourceware.org/git/binutils-gdb.git 4. tsuna/boost.m4#15 5. https://bugzilla.gnome.org/show_bug.cgi?id=641416 6. https://stackoverflow.com/questions/12629042/g-4-6-real-error-unrecognized-option-r 7. https://curl.haxx.se/mail/archive-2014-11/0005.html 8. https://gcc.gnu.org/gcc-4.6/changes.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
gitster
pushed a commit
to git/git
that referenced
this issue
May 19, 2019
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. This CC_LD_DYNPATH flag is really obscure, and I don't expect anyone except those working on git development ever use this. It's not needed to simply link to libraries like say libpcre, but *only* for those cases where we're linking to such a library not present in the OS's library directories. See e.g. ldconfig(8) on Linux for more details. I use this to compile my git with a LIBPCREDIR=$HOME/g/pcre2/inst as I'm building that from source, but someone maintaining an OS package is almost certainly not going to use this. They're just going to set USE_LIBPCRE=YesPlease after installing the libpcre dependency, which'll point to OS libraries which ld(1) will find without the help of CC_LD_DYNPATH. Another thing that helps mitigate any potential breakage is that we detect the right type of invocation in configure.ac, which e.g. HP/UX uses[1], as does IBM's AIX package[2]. From what I can tell both AIX and Solaris packagers are building git with GCC, so I'm not adding a corresponding config.mak.uname default to cater to their OS-native linkers. Now for an overview of past development in this area: Our use of "-R" dates back to 455a7f3 ("More portability.", 2005-09-30). Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27) 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) 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[3] a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20). Further reading and prior art can be found at [4][5][6][7]. Making a plain "-R" an error seems from reading those reports to have been introduced in GCC 4.6 released on March 25, 2011[8], 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. 1. https://public-inbox.org/git/20190516093412.14795-1-avarab@gmail.com/ 2. https://www.ibm.com/developerworks/aix/library/aix-toolbox/alpha.html 3. git://sourceware.org/git/binutils-gdb.git 4. tsuna/boost.m4#15 5. https://bugzilla.gnome.org/show_bug.cgi?id=641416 6. https://stackoverflow.com/questions/12629042/g-4-6-real-error-unrecognized-option-r 7. https://curl.haxx.se/mail/archive-2014-11/0005.html 8. https://gcc.gnu.org/gcc-4.6/changes.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For compatibility with GCC 4.6.
Also submitting this to:
https://bugzilla.gnome.org/show_bug.cgi?id=641416
--- ../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 elseThe text was updated successfully, but these errors were encountered: