search

Thefrank / dotnet-freebsd-crossbuild

Bash script and patches for building dotNET for FreeBSD under Linux
31 stars 3 forks source link

patch_runtimeRTM: Updating printf calls #2

Closed spchamp closed 2 years ago

spchamp commented 2 years ago

Adding patches for dotnet/runtime cross build in the runtimeRTM patch

  /usr/local/src/dotsys_wk/crossbuild/build/runtime/src/coreclr/debug/daccess/daccess.cpp:7264:38: error: invalid suffix 'x' on integer constant
      *dacTableAddress = baseAddress + DAC_TABLE_RVA;
                                       ^
  /usr/local/src/dotsys_wk/crossbuild/build/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/inc/dactablerva.h:1:24: note: expanded from macro 'DAC_TABLE_RVA'
  #define DAC_TABLE_RVA 0x          6c0df8
                         ^
  1 error generated.

In the amended patch, the git index information has been produced from a local Git branch build/v6.0.3 on the dotnet/runtime source tag v6.0.3

(cherry picked from commit e42671f7c1e699da4955ea9fc6f57f41c6391ffc)

In the progress report, I'm afraid I'll need to update my entrypoint.sh scripting. The build completed for dotnet/runtime though, building for FreeBSD 12.3 base system on an openSUSE Tumbleweed machine (EFI/GPT) under Bhyve

spchamp commented 2 years ago

I may need to update that patch, or to review the patched shell script again. I'd translated an "\n" to a "\t" in the patch for the shell checks on the cmake scripting. With this change, it might persistently invalidate the internal string check in the scripting for the cmakefiles rebuild. it should continue to build past that point, however, with new cmakefiles.

The patch on the patch for src/coreclr/pal/tools/gen-dactable-rva.sh is usable, I think

If any further progress report for the cross-build may be of interest:

Using the original patches with the scripting in the contrib 'thinkum' branch, the build stopped after the dotnet/runtime build. I'll try to incorporate that as a feature in the scripting.

The build had produced approx 5.0GiB of files in build/runtime/artifacts/ under the work tree. I've edited out some of my earlier remarks, here, on taking a look at the files it produced.

Reveiwing the scripting in build.sh now, I can see where the tar.gz bundles are copied in for each successive build. Will try out the dotnet-runtime-6.0.3-freebsd-x64.tar.gz shortly

With the tar.gz bundles and nupkg files, the runtime/artifacts/packages/Release/Shipping/ directory contains approx 1.1GiB of files. I'll try to find some way to host those independent of GitHub, for this local build, along with the buld-deps as used locally.

Thefrank commented 2 years ago

Thanks for the contributions! I should be able to take a look at these in the next day or two

Thefrank commented 2 years ago

Sorry for the wait! Looks good on my end for docker builds

Thanks for the contribution!

Thefrank commented 2 years ago

@spchamp

Command: ROOTFS_DIR=/home/frank/freebsd/ ./build.sh -c Release -cross -os freebsd -ci /p:OfficialBuildId=$(date +%Y%m%d)-99 OS: Ubuntu 18.04 uname -a: Linux buildbot 5.17.3-051703-generic #202204131853 SMP PREEMPT Wed Apr 13 18:57:08 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux using v6.0.3 runtime tag and a crossrootfs of FreeBSD 12.3 generated from runtime/eng/common/cross/build-rootfs.sh (aka non-docker build) the build will throw this non-fatally:

  Scanning dependencies of target dactablerva_header
  Scanning dependencies of target inject_debug_resources_coreclr
  [ 97%] /home/frank/runtime/artifacts/obj/coreclr/FreeBSD.x64.Release/inc/dactablerva.h
  [ 97%] Built target inject_debug_resources_coreclr
  /home/frank/runtime/src/coreclr/pal/tools/gen-dactable-rva.sh: line 18: printf: 6a3598: invalid number
  [ 97%] Built target dactablerva_header
  Scanning dependencies of target daccess

the output from (printf "%016x\n" 6a3598 I think?) likely looks like 0000000000000006 vs 6a3598 with printf "%016s\n" 6a3598 bsd's printf handles this a bit differently: printf "%016x\n" 6a3598 -> 

printf: 6a3598: not completely converted
0000000000000006

vs printf "%016s\n" 6a3598 -> 

00000000006a3598

The generated runtime atleast passes a simple dotnet --info without issue so I am unsure of the impact