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 455a7f3275 ("More portability.",
2005-09-30). Soon after that in bbfc63dd78 ("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 f5b904db6b ("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. https://github.com/tsuna/boost.m4/issues/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@xxxxxxxxx>
---
Looking at that HP/UX configure patch I was reminded of being annoyed
by the NO_R_TO_GCC_LINKER flag.
Makefile | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index f965509b3c..ce7a489d64 100644
--- a/Makefile
+++ b/Makefile
@@ -265,10 +265,6 @@ all::
#
# Define NO_DEFLATE_BOUND if your zlib does not have deflateBound.
#
-# Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
-# that tells runtime paths to dynamic libraries;
-# "-Wl,-rpath=/path/lib" is used instead.
-#
# Define NO_NORETURN if using buggy versions of gcc 4.6+ and profile feedback,
# as the compiler can crash (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299)
#
@@ -1160,6 +1156,7 @@ endif
# which'll override these defaults.
CFLAGS = -g -O2 -Wall
LDFLAGS =
+CC_LD_DYNPATH = -Wl,-rpath,
BASIC_CFLAGS = -I.
BASIC_LDFLAGS =
@@ -1287,16 +1284,6 @@ ifeq ($(uname_S),Darwin)
PTHREAD_LIBS =
endif
-ifndef CC_LD_DYNPATH
- ifdef NO_R_TO_GCC_LINKER
- # Some gcc does not accept and pass -R to the linker to specify
- # the runtime dynamic library path.
- CC_LD_DYNPATH = -Wl,-rpath,
- else
- CC_LD_DYNPATH = -R
- endif
-endif
-
ifdef NO_LIBGEN_H
COMPAT_CFLAGS += -DNO_LIBGEN_H
COMPAT_OBJS += compat/basename.o
--
2.21.0.1020.gf2820cf01a
