RFR: 8295795: hsdis does not build with binutils 2.39+ [v3]

[Robbin Ehn]

On Thu, 21 Sep 2023 14:45:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted bad change
>
> make/autoconf/lib-hsdis.m4 line 245:
> 
>> 243:     HSDIS_CFLAGS="-DLIBARCH_$OPENJDK_TARGET_CPU_LEGACY_LIB"
>> 244:   elif test "x$BINUTILS_DIR" != x; then
>> 245:     if test -e $BINUTILS_DIR/bfd/.libs/libbfd.a && \
> 
> The use of `.libs` here looks a bit scary. I have not looked in detail at the binutils build system, but it sounds like a temporary/internal file. What is the rationale?

We never do 'make install' , so we are using the internal placement of files already.
Make install do not install some of the dependency we have (some h-files we use are not part of binutils installation, e.g. bfdver.h).

So we are stuck between hard place and a rock, we can't use the installed binutils file-tree, so we must keep using the internal build layout.

> make/autoconf/lib-hsdis.m4 line 259:
> 
>> 257:       # If we have libsframe add it.
>> 258:       if test -e $BINUTILS_DIR/libsframe/.libs/libsframe.a; then
>> 259:         HSDIS_LIBS="$BINUTILS_DIR/bfd/.libs/libbfd.a $BINUTILS_DIR/opcodes/libopcodes.a $BINUTILS_DIR/libiberty/libiberty.a $BINUTILS_DIR/zlib/libz.a $BINUTILS_DIR/libsframe/.libs/libsframe.a"
> 
> Suggestion:
> 
>         HSDIS_LIBS="$HSDIS_LIBS $BINUTILS_DIR/libsframe/.libs/libsframe.a"
> 
> 
> ...with the same caveat as above -- why use '.libs'?

Same answer, that is the layout of the build-tree and that is what we are using,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15138#discussion_r1333949968
PR Review Comment: https://git.openjdk.org/jdk/pull/15138#discussion_r1333951160