[jemalloc|vcpkg_configure_make] update and some script fixes

[Neumann-A]

lets rebuild the world ;)

[github-actions]

You have modified or added at least one vcpkg.json where you should check the license field.

If you feel able to do so, please consider adding a "license" field to the following files:

• ports/jemalloc/vcpkg.json

Valid values for the license field can be found in the documentation

[Neumann-A]

Current CI baseline:

jemalloc:arm64-windows=fail
jemalloc:arm-uwp=fail
jemalloc:x64-linux=fail
jemalloc:x64-osx=fail
jemalloc:x64-uwp=fail
jemalloc:x64-windows-static=fail

[Neumann-A]

@BillyONeal: rsocket ICEd here. Please check the baseline.

[BillyONeal]

@BillyONeal: rsocket ICEd here. Please check the baseline.

#24959

[vicroms]

I'm going to need more explanation on these lines. How does this trick work?

[Neumann-A]

configure wants the following:
a) a successful return code for the compile | true (true is a binary, same as false; available via msys on windows)
b) an output file. Depending on the test it either wants just an object file or an executable. (which is why there are two touch commands)

Be aware that the trick is already used in:

vcpkg/ports/gmp/portfile.cmake

Lines 40 to 44 in 6118049

	if(VCPKG_CROSSCOMPILING)
	# Silly trick to make configure accept CC_FOR_BUILD but in reallity CC_FOR_BUILD is deactivated.
	set(ENV{CC_FOR_BUILD} "touch a.out | touch conftest${VCPKG_HOST_EXECUTABLE_SUFFIX} | true")
	set(ENV{CPP_FOR_BUILD} "touch a.out | touch conftest${VCPKG_HOST_EXECUTABLE_SUFFIX} | true")
	endif()

I am just generalizing it here for all ports.

[cenit]

the trick made gmp fail for me, but @Neumann-A was not able to replicate the issue.
For me the issue was that the executable was not a real working one (while CC_FOR_BUILD should create an executable that the host IS able to run)

[Neumann-A]

For me the issue was that the executable was not a real working one (while CC_FOR_BUILD should create an executable that the host IS able to run)

The question is did it pass configure but failed the build or did it fail configure? I had the issue that the build was failing in libx11 due to that but the real reason was that this PR deactivates implicit cross builds in vcpkg by design. So extra steps have to be taken to re-enable those explicitly. (e.g. by copying the required host artifacts in the buildtree for the target so that make thinks it already build those and doesn't even try to build them. )

[cenit]

configure was failing

[cenit]

the script was not just checking the CC_FOR_BUILD returning true after trying to compile, but it even went on trying to run the simple executable produced, which failed with your trick

[Neumann-A]

Could be this one:

{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for build system executable suffix" >&5
printf %s "checking for build system executable suffix... " >&6; }
if test ${gmp_cv_prog_exeext_for_build+y}
then :
  printf %s "(cached) " >&6
else $as_nop
  cat >conftest.c <<EOF
int
main ()
{
  return 0;
}
EOF
for i in .exe ,ff8 ""; do
  gmp_compile="$CC_FOR_BUILD conftest.c -o conftest$i"
  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$gmp_compile\""; } >&5
  (eval $gmp_compile) 2>&5
  ac_status=$?
  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
  test $ac_status = 0; }; then
    if (./conftest) 2>&5; then
      gmp_cv_prog_exeext_for_build=$i
      break
    fi
  fi
done
rm -f conftest*
if test "${gmp_cv_prog_exeext_for_build+set}" != set; then
  as_fn_error $? "Cannot determine executable suffix" "$LINENO" 5
fi

was the only check i found trying to run the output. since the name of the variable is gmp_cv_prog_exeext_for_build it seems to be specific to gmp. So setting gmp_cv_prog_exeext_for_build by hand should fix that.

[cenit]

yes exactly. I was running on memory and didn't expect you to do the search work for me. Thanks for already finding it out

[JackBoosY]

Ping @vicroms for review again.

[vicroms]

LGTM but I'd like additional review @BillyONeal @ras0219-msft @dan-shaw @JavierMatosD

[m-kuhn]

Are there any questions open regarding the vcpkg_configure_make parts or only the jemalloc parts?
The vcpkg_configure_make related changes are crucial for cross compilation and if these require less discussion they could be split into a separate PR to speed things up.

[BillyONeal]

Thanks for explaining @Neumann-A

[JavierMatosD]

Thanks!