On Thu, 21 Sep 2023 14:45:52 GMT, Magnus Ihse Bursie <i...@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
