[PATCH] Improving HP-UX support

[PATCH] Improving HP-UX support

[Osipov, Michael]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

Hi folks,

please find a patch attached to properly compile and link Git 2.21.0 on 
HP-UX IA64.

The patch includes basically two changes:

* Detection of big endian on HP-UX otherwise SHA1 calc is broken
* Detection of linking style with HP aCC

> export PREFIX=/opt/ports
> export LIBDIR=$PREFIX/lib/hpux32
> export CC=/opt/aCC/bin/aCC
> export CXX=/opt/aCC/bin/aCC
> export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
> export CPPFLAGS="-I$PREFIX/include"
> export LDFLAGS="-L$LIBDIR"
> autoreconf -fi
> $CONFIGURE --with-editor=vim --with-zlib=$PREFIX --with-perl=/usr/bin/perl --with-iconv=$PREFIX \
>   --with-libpcre=$PREFIX --with-gitconfig=$PREFIX/etc/gitconfig --with-gitattributes=$PREFIX/etc/gitattributes \
>   --without-tcltk --disable-pthreads --with-lib=lib/hpux32
> gmake INSTALL=$INSTALL_SH install

Note: I am not subscribed to this list.

Regards,

Michael

[-- Attachment #2: git.patch --]
[-- Type: text/plain, Size: 1294 bytes --]

diff -ur configure.ac configure.ac
--- configure.ac	2019-02-24 16:55:19 +0000
+++ configure.ac	2019-05-08 11:31:42 +0000
@@ -475,8 +475,18 @@
       if test "$git_cv_ld_rpath" = "yes"; then
          CC_LD_DYNPATH=-rpath
       else
-         CC_LD_DYNPATH=
-         AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
+         AC_CACHE_CHECK([if linker supports -Wl,+b,], git_cv_ld_wl_b, [
+            SAVE_LDFLAGS="${LDFLAGS}"
+            LDFLAGS="${SAVE_LDFLAGS} -Wl,+b,/"
+            AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_b=yes], [git_cv_ld_wl_b=no])
+            LDFLAGS="${SAVE_LDFLAGS}"
+         ])
+         if test "$git_cv_ld_wl_b" = "yes"; then
+            CC_LD_DYNPATH=-Wl,+b,
+          else
+             CC_LD_DYNPATH=
+             AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
+          fi
       fi
    fi
 fi
diff -ur sha1dc/sha1.c sha1dc/sha1.c
--- sha1dc/sha1.c	2019-02-24 16:55:19 +0000
+++ sha1dc/sha1.c	2019-05-04 01:26:22 +0000
@@ -93,7 +93,7 @@
 #define SHA1DC_BIGENDIAN
 
 /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */
-#elif (defined(_AIX))
+#elif (defined(_AIX) || defined(__hpux))
 
 /*
  * Defines Big Endian on a whitelist of OSs that are known to be Big

Re: [PATCH] Improving HP-UX support

[Ævar Arnfjörð Bjarmason]

On Wed, May 08 2019, Osipov, Michael wrote:

> Hi folks,

Hi see Documentation/SubmittingPatches for how to submit patches inline
instead of as attachments.

For the sha1dc change it seems trivially correct, but we import that
upstream project as-is, could you please submit a pull request at
https://github.com/cr-marcstevens/sha1collisiondetection then we can
update our version?

> diff -ur configure.ac configure.ac
> --- configure.ac	2019-02-24 16:55:19 +0000
> +++ configure.ac	2019-05-08 11:31:42 +0000
> @@ -475,8 +475,18 @@
>        if test "$git_cv_ld_rpath" = "yes"; then
>           CC_LD_DYNPATH=-rpath
>        else
> -         CC_LD_DYNPATH=
> -         AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
> +         AC_CACHE_CHECK([if linker supports -Wl,+b,], git_cv_ld_wl_b, [
> +            SAVE_LDFLAGS="${LDFLAGS}"
> +            LDFLAGS="${SAVE_LDFLAGS} -Wl,+b,/"
> +            AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_b=yes], [git_cv_ld_wl_b=no])
> +            LDFLAGS="${SAVE_LDFLAGS}"
> +         ])
> +         if test "$git_cv_ld_wl_b" = "yes"; then
> +            CC_LD_DYNPATH=-Wl,+b,
> +          else
> +             CC_LD_DYNPATH=
> +             AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
> +          fi
>        fi
>     fi
>  fi

Do we want to also have something in config.mak.uname to always do this
on HP/UX?

>  /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */
> -#elif (defined(_AIX))
> +#elif (defined(_AIX) || defined(__hpux))

Seems sane, and per my googling even though HP/UX now runs on
little-endian hardware it's always big-endian. But in this manual they
advice doing it at runtime with a TEST_ENDIAN() macro in sys/portal.h:
http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c01921401-1.pdf

Is that something we need to worry about / support? E.g. in the
configure script?

Re: [PATCH] Improving HP-UX support

[Osipov, Michael]

Hey there,

Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
> 
> On Wed, May 08 2019, Osipov, Michael wrote:
> 
>> Hi folks,
> 
> Hi see Documentation/SubmittingPatches for how to submit patches inline
> instead of as attachments.

Do you want me to resend the configure.ac change as per wiki article? I 
can also create a PR on GitHub. I am happy with both as long as I don't 
have to retain the patch for myself only ;-)

> For the sha1dc change it seems trivially correct, but we import that
> upstream project as-is, could you please submit a pull request at
> https://github.com/cr-marcstevens/sha1collisiondetection then we can
> update our version?

Sure thing, will do.

>> diff -ur configure.ac configure.ac
>> --- configure.ac	2019-02-24 16:55:19 +0000
>> +++ configure.ac	2019-05-08 11:31:42 +0000
>> @@ -475,8 +475,18 @@
>>         if test "$git_cv_ld_rpath" = "yes"; then
>>            CC_LD_DYNPATH=-rpath
>>         else
>> -         CC_LD_DYNPATH=
>> -         AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
>> +         AC_CACHE_CHECK([if linker supports -Wl,+b,], git_cv_ld_wl_b, [
>> +            SAVE_LDFLAGS="${LDFLAGS}"
>> +            LDFLAGS="${SAVE_LDFLAGS} -Wl,+b,/"
>> +            AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_b=yes], [git_cv_ld_wl_b=no])
>> +            LDFLAGS="${SAVE_LDFLAGS}"
>> +         ])
>> +         if test "$git_cv_ld_wl_b" = "yes"; then
>> +            CC_LD_DYNPATH=-Wl,+b,
>> +          else
>> +             CC_LD_DYNPATH=
>> +             AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
>> +          fi
>>         fi
>>      fi
>>   fi
> 
> Do we want to also have something in config.mak.uname to always do this
> on HP/UX?

I am not convinced by that. I wouldn't mix operating system with 
compiler settings. One could also use GCC on HP-UX. The one above is for 
HP aCC.

>>   /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */
>> -#elif (defined(_AIX))
>> +#elif (defined(_AIX) || defined(__hpux))
> 
> Seems sane, and per my googling even though HP/UX now runs on
> little-endian hardware it's always big-endian. But in this manual they
> advice doing it at runtime with a TEST_ENDIAN() macro in sys/portal.h:
> http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c01921401-1.pdf
> 
> Is that something we need to worry about / support? E.g. in the
> configure script?
> 

That'd be much more work to extend configure.ac for that because is a 
runtime check. Since there are no real products vailable on x86 for 
HP-UX I'd neglect that. Our HPE salesman told us that this will be 
available somewhere in the future. So, I think this is very good for now.

Michael

[PATCH] sha1dc: update from upstream

[Ævar Arnfjörð Bjarmason]

Update sha1dc from the latest version by the upstream
maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
sha1dc with UBSan", 2019-03-12) for the last update.

This fixes an issue where HP-UX IA64 was wrongly detected as a
Little-endian instead of a Big-endian system, see [2] and [3].

1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/855827c583bc30645ba427885caa40c5b81764d2
2. https://public-inbox.org/git/603989bd-f86d-c61d-c6f5-fb6748a65ba9@siemens.com/
3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/50

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

n Thu, May 09 2019, Osipov, Michael wrote:

> Hey there,
>
> Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
>>
>> On Wed, May 08 2019, Osipov, Michael wrote:
>>
>>> Hi folks,
>>
>> Hi see Documentation/SubmittingPatches for how to submit patches inline
>> instead of as attachments.
>
> Do you want me to resend the configure.ac change as per wiki article?
> I can also create a PR on GitHub. I am happy with both as long as I
> don't have to retain the patch for myself only ;-)

Yeah that patch to git.git should be done separately. I see your PR
went in upstream, here's a patch to update our code to match.

> That'd be much more work to extend configure.ac for that because is a
> runtime check. Since there are no real products vailable on x86 for
> HP-UX I'd neglect that. Our HPE salesman told us that this will be
> available somewhere in the future. So, I think this is very good for
> now.

Sure, makes sense. I'm not familiar with HP/UX. So just thought I'd
ask.

 sha1collisiondetection | 2 +-
 sha1dc/sha1.c          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sha1collisiondetection b/sha1collisiondetection
index 16033998da..855827c583 160000
--- a/sha1collisiondetection
+++ b/sha1collisiondetection
@@ -1 +1 @@
-Subproject commit 16033998da4b273aebd92c84b1e1b12e4aaf7009
+Subproject commit 855827c583bc30645ba427885caa40c5b81764d2
diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
index 5931cf25d5..9d3cf81d4d 100644
--- a/sha1dc/sha1.c
+++ b/sha1dc/sha1.c
@@ -93,7 +93,7 @@
 #define SHA1DC_BIGENDIAN
 
 /* Not under GCC-alike or glibc or *BSD or newlib or <processor whitelist> */
-#elif (defined(_AIX))
+#elif (defined(_AIX) || defined(__hpux))
 
 /*
  * Defines Big Endian on a whitelist of OSs that are known to be Big
-- 
2.21.0.1020.gf2820cf01a

Re: [PATCH] sha1dc: update from upstream

[Osipov, Michael]

Hi,

Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
> Update sha1dc from the latest version by the upstream
> maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
> sha1dc with UBSan", 2019-03-12) for the last update.
> 
> This fixes an issue where HP-UX IA64 was wrongly detected as a
> Little-endian instead of a Big-endian system, see [2] and [3].
> 
> 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/855827c583bc30645ba427885caa40c5b81764d2
> 2. https://public-inbox.org/git/603989bd-f86d-c61d-c6f5-fb6748a65ba9@siemens.com/
> 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/50
> 
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> 
> n Thu, May 09 2019, Osipov, Michael wrote:
> 
>> Hey there,
>>
>> Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
>>>
>>> On Wed, May 08 2019, Osipov, Michael wrote:
>>>
>>>> Hi folks,
>>>
>>> Hi see Documentation/SubmittingPatches for how to submit patches inline
>>> instead of as attachments.
>>
>> Do you want me to resend the configure.ac change as per wiki article?
>> I can also create a PR on GitHub. I am happy with both as long as I
>> don't have to retain the patch for myself only ;-)
> 
> Yeah that patch to git.git should be done separately. I see your PR
> went in upstream, here's a patch to update our code to match.

To avoid misunderstandings, I have factored out the Git patch and 
created a PR: https://github.com/git/git/pull/608

Looks good to me now:
> osipovmi@deblndw024v:~/git
> $ uname -a
> HP-UX deblndw0 B.11.31 U ia64 HP-UX
> osipovmi@deblndw024v:~/git
> $ ./git --version
> git version 2.22.0.rc0.dirty
> osipovmi@deblndw024v:~/git
> $ ldd ./git
> 
> ./git:
>         libz.so =>      /opt/ports/lib/hpux32/libz.so
>         libiconv.so.8 =>        /opt/ports/lib/hpux32/libiconv.so.8
>         libintl.so.9 => /opt/ports/lib/hpux32/libintl.so.9
>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>         libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

Looking forward for a merge.

Regards,

Michael

Re: [PATCH] sha1dc: update from upstream

[Ævar Arnfjörð Bjarmason]

On Tue, May 14 2019, Osipov, Michael wrote:

> Hi,
>
> Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
>> Update sha1dc from the latest version by the upstream
>> maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
>> sha1dc with UBSan", 2019-03-12) for the last update.
>>
>> This fixes an issue where HP-UX IA64 was wrongly detected as a
>> Little-endian instead of a Big-endian system, see [2] and [3].
>>
>> 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/855827c583bc30645ba427885caa40c5b81764d2
>> 2. https://public-inbox.org/git/603989bd-f86d-c61d-c6f5-fb6748a65ba9@siemens.com/
>> 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/50
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>
>> n Thu, May 09 2019, Osipov, Michael wrote:
>>
>>> Hey there,
>>>
>>> Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
>>>>
>>>> On Wed, May 08 2019, Osipov, Michael wrote:
>>>>
>>>>> Hi folks,
>>>>
>>>> Hi see Documentation/SubmittingPatches for how to submit patches inline
>>>> instead of as attachments.
>>>
>>> Do you want me to resend the configure.ac change as per wiki article?
>>> I can also create a PR on GitHub. I am happy with both as long as I
>>> don't have to retain the patch for myself only ;-)
>>
>> Yeah that patch to git.git should be done separately. I see your PR
>> went in upstream, here's a patch to update our code to match.
>
> To avoid misunderstandings, I have factored out the Git patch and
> created a PR: https://github.com/git/git/pull/608

Thanks. If you want to submit it for inclusion you'll need to submit it
as a patch here to the ML as described here:
https://github.com/git/git/blob/master/Documentation/SubmittingPatches

Or you can use this pull-request-by-proxy thing:
https://gitgitgadget.github.io/

Or if you don't want to deal with any of that crap just say and I'll
E-Mail this to the list for you. Just want to give you a chance to do it
:)

> Looks good to me now:
>> osipovmi@deblndw024v:~/git
>> $ uname -a
>> HP-UX deblndw0 B.11.31 U ia64 HP-UX
>> osipovmi@deblndw024v:~/git
>> $ ./git --version
>> git version 2.22.0.rc0.dirty
>> osipovmi@deblndw024v:~/git
>> $ ldd ./git
>>
>> ./git:
>>         libz.so =>      /opt/ports/lib/hpux32/libz.so
>>         libiconv.so.8 =>        /opt/ports/lib/hpux32/libiconv.so.8
>>         libintl.so.9 => /opt/ports/lib/hpux32/libintl.so.9
>>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>>         libc.so.1 =>    /usr/lib/hpux32/libc.so.1
>>         libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
>
> Looking forward for a merge.
>
> Regards,
>
> Michael

Re: [PATCH] sha1dc: update from upstream

[Osipov, Michael]

Am 2019-05-15 um 13:48 schrieb Ævar Arnfjörð Bjarmason:
> 
> On Tue, May 14 2019, Osipov, Michael wrote:
> 
>> Hi,
>>
>> Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
>>> Update sha1dc from the latest version by the upstream
>>> maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
>>> sha1dc with UBSan", 2019-03-12) for the last update.
>>>
>>> This fixes an issue where HP-UX IA64 was wrongly detected as a
>>> Little-endian instead of a Big-endian system, see [2] and [3].
>>>
>>> 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/855827c583bc30645ba427885caa40c5b81764d2
>>> 2. https://public-inbox.org/git/603989bd-f86d-c61d-c6f5-fb6748a65ba9@siemens.com/
>>> 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/50
>>>
>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>> ---
>>>
>>> n Thu, May 09 2019, Osipov, Michael wrote:
>>>
>>>> Hey there,
>>>>
>>>> Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
>>>>>
>>>>> On Wed, May 08 2019, Osipov, Michael wrote:
>>>>>
>>>>>> Hi folks,
>>>>>
>>>>> Hi see Documentation/SubmittingPatches for how to submit patches inline
>>>>> instead of as attachments.
>>>>
>>>> Do you want me to resend the configure.ac change as per wiki article?
>>>> I can also create a PR on GitHub. I am happy with both as long as I
>>>> don't have to retain the patch for myself only ;-)
>>>
>>> Yeah that patch to git.git should be done separately. I see your PR
>>> went in upstream, here's a patch to update our code to match.
>>
>> To avoid misunderstandings, I have factored out the Git patch and
>> created a PR: https://github.com/git/git/pull/608
> 
> Thanks. If you want to submit it for inclusion you'll need to submit it
> as a patch here to the ML as described here:
> https://github.com/git/git/blob/master/Documentation/SubmittingPatches
> 
> Or you can use this pull-request-by-proxy thing:
> https://gitgitgadget.github.io/
> 
> Or if you don't want to deal with any of that crap just say and I'll
> E-Mail this to the list for you. Just want to give you a chance to do it
> :)

Yes, please do so. It seems like our corporate mail relay server does 
not allow sending emails outside of our dns namespace. I get bounces 
from mailer daemon.

Michael

Re: [PATCH] sha1dc: update from upstream

[Ævar Arnfjörð Bjarmason]

On Thu, May 16 2019, Osipov, Michael wrote:

> Am 2019-05-15 um 13:48 schrieb Ævar Arnfjörð Bjarmason:
>>
>> On Tue, May 14 2019, Osipov, Michael wrote:
>>
>>> Hi,
>>>
>>> Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
>>>> Update sha1dc from the latest version by the upstream
>>>> maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
>>>> sha1dc with UBSan", 2019-03-12) for the last update.
>>>>
>>>> This fixes an issue where HP-UX IA64 was wrongly detected as a
>>>> Little-endian instead of a Big-endian system, see [2] and [3].
>>>>
>>>> 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/855827c583bc30645ba427885caa40c5b81764d2
>>>> 2. https://public-inbox.org/git/603989bd-f86d-c61d-c6f5-fb6748a65ba9@siemens.com/
>>>> 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/50
>>>>
>>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>>> ---
>>>>
>>>> n Thu, May 09 2019, Osipov, Michael wrote:
>>>>
>>>>> Hey there,
>>>>>
>>>>> Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
>>>>>>
>>>>>> On Wed, May 08 2019, Osipov, Michael wrote:
>>>>>>
>>>>>>> Hi folks,
>>>>>>
>>>>>> Hi see Documentation/SubmittingPatches for how to submit patches inline
>>>>>> instead of as attachments.
>>>>>
>>>>> Do you want me to resend the configure.ac change as per wiki article?
>>>>> I can also create a PR on GitHub. I am happy with both as long as I
>>>>> don't have to retain the patch for myself only ;-)
>>>>
>>>> Yeah that patch to git.git should be done separately. I see your PR
>>>> went in upstream, here's a patch to update our code to match.
>>>
>>> To avoid misunderstandings, I have factored out the Git patch and
>>> created a PR: https://github.com/git/git/pull/608
>>
>> Thanks. If you want to submit it for inclusion you'll need to submit it
>> as a patch here to the ML as described here:
>> https://github.com/git/git/blob/master/Documentation/SubmittingPatches
>>
>> Or you can use this pull-request-by-proxy thing:
>> https://gitgitgadget.github.io/
>>
>> Or if you don't want to deal with any of that crap just say and I'll
>> E-Mail this to the list for you. Just want to give you a chance to do it
>> :)
>
> Yes, please do so. It seems like our corporate mail relay server does
> not allow sending emails outside of our dns namespace. I get bounces
> from mailer daemon.

Hi. No problem, but I just noticed your commit is missing a
signed-off-by (required for inclusion in git.git), please "git commit
--amend -s" it and re-push that PR, then I can pull it from there.

Re: [PATCH] sha1dc: update from upstream

[Osipov, Michael]

Am 2019-05-16 um 10:31 schrieb Ævar Arnfjörð Bjarmason:
> 
> On Thu, May 16 2019, Osipov, Michael wrote:
> 
>> Am 2019-05-15 um 13:48 schrieb Ævar Arnfjörð Bjarmason:
>>>
>>> On Tue, May 14 2019, Osipov, Michael wrote:
>>>
>>>> Hi,
>>>>
>>>> Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
>>>>> Update sha1dc from the latest version by the upstream
>>>>> maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
>>>>> sha1dc with UBSan", 2019-03-12) for the last update.
>>>>>
>>>>> This fixes an issue where HP-UX IA64 was wrongly detected as a
>>>>> Little-endian instead of a Big-endian system, see [2] and [3].
>>>>>
>>>>> 1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/855827c583bc30645ba427885caa40c5b81764d2
>>>>> 2. https://public-inbox.org/git/603989bd-f86d-c61d-c6f5-fb6748a65ba9@siemens.com/
>>>>> 3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/50
>>>>>
>>>>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>>>> ---
>>>>>
>>>>> n Thu, May 09 2019, Osipov, Michael wrote:
>>>>>
>>>>>> Hey there,
>>>>>>
>>>>>> Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
>>>>>>>
>>>>>>> On Wed, May 08 2019, Osipov, Michael wrote:
>>>>>>>
>>>>>>>> Hi folks,
>>>>>>>
>>>>>>> Hi see Documentation/SubmittingPatches for how to submit patches inline
>>>>>>> instead of as attachments.
>>>>>>
>>>>>> Do you want me to resend the configure.ac change as per wiki article?
>>>>>> I can also create a PR on GitHub. I am happy with both as long as I
>>>>>> don't have to retain the patch for myself only ;-)
>>>>>
>>>>> Yeah that patch to git.git should be done separately. I see your PR
>>>>> went in upstream, here's a patch to update our code to match.
>>>>
>>>> To avoid misunderstandings, I have factored out the Git patch and
>>>> created a PR: https://github.com/git/git/pull/608
>>>
>>> Thanks. If you want to submit it for inclusion you'll need to submit it
>>> as a patch here to the ML as described here:
>>> https://github.com/git/git/blob/master/Documentation/SubmittingPatches
>>>
>>> Or you can use this pull-request-by-proxy thing:
>>> https://gitgitgadget.github.io/
>>>
>>> Or if you don't want to deal with any of that crap just say and I'll
>>> E-Mail this to the list for you. Just want to give you a chance to do it
>>> :)
>>
>> Yes, please do so. It seems like our corporate mail relay server does
>> not allow sending emails outside of our dns namespace. I get bounces
>> from mailer daemon.
> 
> Hi. No problem, but I just noticed your commit is missing a
> signed-off-by (required for inclusion in git.git), please "git commit
> --amend -s" it and re-push that PR, then I can pull it from there.

Done as requested!

Michael

[PATCH] configure: Detect linking style for HP aCC on HP-UX

[Ævar Arnfjörð Bjarmason]

From: Michael Osipov <michael.osipov@siemens.com>

HP aCC does not accept any of the previously tested CC_LD_DYNPATH
formats, but only its own[1] "-Wl,+b" format. Add it to configure.ac.

1. http://nixdoc.net/man-pages/hp-ux/man1/ld_pa.1.html

Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

I took the liberty of slightly amending the commit message.

 configure.ac | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index be3b55f1cc..a43b476402 100644
--- a/configure.ac
+++ b/configure.ac
@@ -475,8 +475,18 @@ else
       if test "$git_cv_ld_rpath" = "yes"; then
          CC_LD_DYNPATH=-rpath
       else
-         CC_LD_DYNPATH=
-         AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
+         AC_CACHE_CHECK([if linker supports -Wl,+b,], git_cv_ld_wl_b, [
+            SAVE_LDFLAGS="${LDFLAGS}"
+            LDFLAGS="${SAVE_LDFLAGS} -Wl,+b,/"
+            AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_b=yes], [git_cv_ld_wl_b=no])
+            LDFLAGS="${SAVE_LDFLAGS}"
+         ])
+         if test "$git_cv_ld_wl_b" = "yes"; then
+            CC_LD_DYNPATH=-Wl,+b,
+          else
+             CC_LD_DYNPATH=
+             AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
+          fi
       fi
    fi
 fi
-- 
2.21.0.1020.gf2820cf01a

[PATCH] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Ævar Arnfjörð Bjarmason]

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@gmail.com>
---

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

Re: [PATCH] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Jeff King]

On Thu, May 16, 2019 at 08:05:21PM +0200, Ævar Arnfjörð Bjarmason wrote:

> 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.

So...does this mean with just your patch that the build is now broken on
AIX if you use CURLDIR?

Far be it from me to care about AIX, but it seems like this is ripe for
regressions, because we don't know which platforms were relying on "-R"
instead of "-Wl,-rpath", and now everybody will be using the latter by
default.

-Peff

Re: [PATCH] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Far be it from me to care about AIX, but it seems like this is ripe for
> regressions, because we don't know which platforms were relying on "-R"
> instead of "-Wl,-rpath", and now everybody will be using the latter by
> default.

I do not have a stake in AIX, either, but I had the same reaction.

Those who found having to give NO_R_TO_GCC_LINKER=NoThanks annoying
could have passed CC_LD_DYNPATH=-Wl,-rpath instead, but that is not
much shorter or sweeter X-<; with this change, they do not have to
do anything, but those who are broken can pass CC_LD_DYNPATH=-R to
unbreak it.  So it may not be the end of the world, but this move
certainly smells like robbing non-GCC users to pay GCC users to me.

Re: [PATCH] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Jeff King]

On Fri, May 17, 2019 at 08:21:09AM +0900, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Far be it from me to care about AIX, but it seems like this is ripe for
> > regressions, because we don't know which platforms were relying on "-R"
> > instead of "-Wl,-rpath", and now everybody will be using the latter by
> > default.
> 
> I do not have a stake in AIX, either, but I had the same reaction.
> 
> Those who found having to give NO_R_TO_GCC_LINKER=NoThanks annoying
> could have passed CC_LD_DYNPATH=-Wl,-rpath instead, but that is not
> much shorter or sweeter X-<; with this change, they do not have to
> do anything, but those who are broken can pass CC_LD_DYNPATH=-R to
> unbreak it.  So it may not be the end of the world, but this move
> certainly smells like robbing non-GCC users to pay GCC users to me.

Thanks, I wasn't quite clear on whether there was an escape hatch for
people who were broken (I took Ævar's "perhaps we should follow this up"
meaning we needed to add new knobs, but it is really just "perhaps we
should set this existing knob by default on AIX"). So that at least
quells the worst of my worries.

After that, I agree it's now just a question of the default. I don't
have a sense whether the majority is helped or hurt here (I admit that I
did not even know about these flags, despite compiling with gcc for the
past 13 years, so possibly everybody was perfectly happy with the
existing behavior).

-Peff

[PATCH v2] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Ævar Arnfjörð Bjarmason]

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 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[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. https://github.com/tsuna/boost.m4/issues/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>
---

On Fri, May 17 2019, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
>
>> Far be it from me to care about AIX, but it seems like this is ripe for
>> regressions, because we don't know which platforms were relying on "-R"
>> instead of "-Wl,-rpath", and now everybody will be using the latter by
>> default.
>
> I do not have a stake in AIX, either, but I had the same reaction.

I did a bad job of summarizing why this change makes sense. Here's a
v2 with a changed commit message. The first 4 pargaraphs are most
relevant.

Range-diff:
1:  bd9558b1cf ! 1:  56abcd0fae Makefile: remove the NO_R_TO_GCC_LINKER flag
    @@ -2,13 +2,34 @@
     
         Makefile: remove the NO_R_TO_GCC_LINKER flag
     
    -    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.
    +    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.
     
    -    How we invoke the linker to do this can still be overridden with
    -    CC_LD_DYNPATH, as seen in our configure.ac script.
    +    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 455a7f3275 ("More portability.",
         2005-09-30). Soon after that in bbfc63dd78 ("gcc does not necessarily
    @@ -22,32 +43,24 @@
     
         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.
    +    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 [2][3][4][5]. Making a
    +    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, but I couldn't
    +    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. 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
    +    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. https://github.com/tsuna/boost.m4/issues/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>
     

 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

Re: [PATCH v2] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> 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.
> ...
> 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=".

Yeah, I recall I had to add -R back when I was with my previous
employer, where I had Sun with GNU toolchain as the primary
environment and many libraries were custom built outside the system
path.


> 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.
> -#

I am not sure if -R was a GCC-only thing; we might want to, instead
of removing this seciton, replace it with something like

    # Use "CC_LD_DYNPATH = -R" if your compiler uses "-R/path/to/lib"
    # to specify the runtime paths to dynamic libraries.  These days,
    # GCC uses -Wl,-rpath=/path/to/lib and that is used by default
    # instead.

to help those whose build suddenly starts breaking.

   >  # 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 =

Or it could be a single liner at this point in the file, perhaps

    # Really old GCC used "CC_LD_DYNPATH = -R" for the runtime dynlib path

> +CC_LD_DYNPATH = -Wl,-rpath,

Re: [PATCH v2] Makefile: remove the NO_R_TO_GCC_LINKER flag

[Jeff King]

On Fri, May 17, 2019 at 11:58:47PM +0200, Ævar Arnfjörð Bjarmason wrote:

> On Fri, May 17 2019, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> >
> >> Far be it from me to care about AIX, but it seems like this is ripe for
> >> regressions, because we don't know which platforms were relying on "-R"
> >> instead of "-Wl,-rpath", and now everybody will be using the latter by
> >> default.
> >
> > I do not have a stake in AIX, either, but I had the same reaction.
> 
> I did a bad job of summarizing why this change makes sense. Here's a
> v2 with a changed commit message. The first 4 pargaraphs are most
> relevant.

Thanks for the additional context. After reading the revised
explanation, I agree it's probably OK to move in this direction.

-Peff

Re: [PATCH] configure: Detect linking style for HP aCC on HP-UX

[Osipov, Michael]

Am 2019-05-16 um 11:34 schrieb Ævar Arnfjörð Bjarmason:
> From: Michael Osipov <michael.osipov@siemens.com>
> 
> HP aCC does not accept any of the previously tested CC_LD_DYNPATH
> formats, but only its own[1] "-Wl,+b" format. Add it to configure.ac.
> 
> 1. http://nixdoc.net/man-pages/hp-ux/man1/ld_pa.1.html
> 
> Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> 
> I took the liberty of slightly amending the commit message.
> 
>   configure.ac | 14 ++++++++++++--
>   1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index be3b55f1cc..a43b476402 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -475,8 +475,18 @@ else
>         if test "$git_cv_ld_rpath" = "yes"; then
>            CC_LD_DYNPATH=-rpath
>         else
> -         CC_LD_DYNPATH=
> -         AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
> +         AC_CACHE_CHECK([if linker supports -Wl,+b,], git_cv_ld_wl_b, [
> +            SAVE_LDFLAGS="${LDFLAGS}"
> +            LDFLAGS="${SAVE_LDFLAGS} -Wl,+b,/"
> +            AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_b=yes], [git_cv_ld_wl_b=no])
> +            LDFLAGS="${SAVE_LDFLAGS}"
> +         ])
> +         if test "$git_cv_ld_wl_b" = "yes"; then
> +            CC_LD_DYNPATH=-Wl,+b,
> +          else
> +             CC_LD_DYNPATH=
> +             AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
> +          fi
>         fi
>      fi
>   fi
> 

I can see that this one has not yet been committed nor my PR has been 
pulled.

Any chances to get this into master?

Michael

Re: [PATCH] configure: Detect linking style for HP aCC on HP-UX

[Junio C Hamano]

"Osipov, Michael" <michael.osipov@siemens.com> writes:

> Am 2019-05-16 um 11:34 schrieb Ævar Arnfjörð Bjarmason:
>> From: Michael Osipov <michael.osipov@siemens.com>
>>
>> HP aCC does not accept any of the previously tested CC_LD_DYNPATH
>> formats, but only its own[1] "-Wl,+b" format. Add it to configure.ac.
>>
>> 1. http://nixdoc.net/man-pages/hp-ux/man1/ld_pa.1.html
>>
>> Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>
>> I took the liberty of slightly amending the commit message.
>>
>>   configure.ac | 14 ++++++++++++--
>>   1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index be3b55f1cc..a43b476402 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -475,8 +475,18 @@ else
>>         if test "$git_cv_ld_rpath" = "yes"; then
>>            CC_LD_DYNPATH=-rpath
>>         else
>> -         CC_LD_DYNPATH=
>> -         AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
>> +         AC_CACHE_CHECK([if linker supports -Wl,+b,], git_cv_ld_wl_b, [
>> +            SAVE_LDFLAGS="${LDFLAGS}"
>> +            LDFLAGS="${SAVE_LDFLAGS} -Wl,+b,/"
>> +            AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_wl_b=yes], [git_cv_ld_wl_b=no])
>> +            LDFLAGS="${SAVE_LDFLAGS}"
>> +         ])
>> +         if test "$git_cv_ld_wl_b" = "yes"; then
>> +            CC_LD_DYNPATH=-Wl,+b,
>> +          else
>> +             CC_LD_DYNPATH=
>> +             AC_MSG_WARN([linker does not support runtime path to dynamic libraries])
>> +          fi
>>         fi
>>      fi
>>   fi
>>
>
> I can see that this one has not yet been committed nor my PR has been
> pulled.
>
> Any chances to get this into master?
>
> Michael

Sorry, it jsut fell of the cracks.  The way the new test was added
looks very good --- any platform that is happy with the existing
test will continue to function the same way, and a platform that
knows -Wl,+b would use it instead of failing.

Will pick it up.

Thanks.