[vcpkg scripts] Add platform support for Solaris and illumos

[trisk]

This add support for Solaris and illumos. Tested building several ports on illumos/amd64 (OmniOS with clang 18 from pkgsrc). Will be submitting fixes for ports that need them as separate PRs. Depends on: https://github.com/microsoft/vcpkg-tool/pull/1684

[trisk]

Interestingly, there is a new x64_osx test failure in the newly added tar check, suggesting it does not actually support archives with pax extended headers either. We normally use a prebuilt vcpkg-tool there, but I wonder what happens with the real release tarball.

[BillyONeal]

Interestingly, there is a new x64_osx test failure in the newly added tar check, suggesting it does not actually support archives with pax extended headers either. We normally use a prebuilt vcpkg-tool there, but I wonder what happens with the real release tarball.

vcpkg@CPPMAC-ARM64-05 test % curl -L -o test.tar.gz https://github.com/microsoft/vcpkg-tool/archive/refs/tags/2025-06-02.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 2833k    0 2833k    0     0  2860k      0 --:--:-- --:--:-- --:--:-- 5392k
vcpkg@CPPMAC-ARM64-05 test % tar xf test.tar.gz
vcpkg@CPPMAC-ARM64-05 test % ls
test.tar.gz             vcpkg-tool-2025-06-02
vcpkg@CPPMAC-ARM64-05 test % tar --version
bsdtar 3.5.3 - libarchive 3.5.3 zlib/1.2.12 liblzma/5.4.3 bz2lib/1.0.8
vcpkg@CPPMAC-ARM64-05 test %

Something about the test doesn't seem to match up with 'reality' of extracting our tool sources?

[trisk]

Interestingly, there is a new x64_osx test failure in the newly added tar check, suggesting it does not actually support archives with pax extended headers either. We normally use a prebuilt vcpkg-tool there, but I wonder what happens with the real release tarball.

vcpkg@CPPMAC-ARM64-05 test % curl -L -o test.tar.gz https://github.com/microsoft/vcpkg-tool/archive/refs/tags/2025-06-02.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 2833k    0 2833k    0     0  2860k      0 --:--:-- --:--:-- --:--:-- 5392k
vcpkg@CPPMAC-ARM64-05 test % tar xf test.tar.gz
vcpkg@CPPMAC-ARM64-05 test % ls
test.tar.gz             vcpkg-tool-2025-06-02
vcpkg@CPPMAC-ARM64-05 test % tar --version
bsdtar 3.5.3 - libarchive 3.5.3 zlib/1.2.12 liblzma/5.4.3 bz2lib/1.0.8
vcpkg@CPPMAC-ARM64-05 test %

Something about the test doesn't seem to match up with 'reality' of extracting our tool sources?

Updated the test to be libarchive compatible (and also search for bsdtar or star as shipped in pkgsrc), and fixed the error message from bootstrap.sh so it refers to tar instead of the last failed command.

[BillyONeal]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[BillyONeal]

@ras0219-msft points out something: we require unzip anyway. Could we use the .zip instead of the .tar.gz to avoid the pax header thing entirely?

Otherwise we would prefer to use the actual sources as the test even if that makes the overall structure more complex so that we don't need to check in a binary file. (The xz situation is fresh in our minds)

[trisk]

The added binary file makes me nervous but not an over my dead body thing yet.... what does this comment mean?

This was a chunk of one of my public keys I was using in place of the hex string comments that I assume are git hashes in the original release archives, but I forgot to convert it to hex, should be: 52 comment=526c4a4652534251515578465531524a546b554b

[trisk]

@ras0219-msft points out something: we require unzip anyway. Could we use the .zip instead of the .tar.gz to avoid the pax header thing entirely?

Otherwise we would prefer to use the actual sources as the test even if that makes the overall structure more complex so that we don't need to check in a binary file. (The xz situation is fresh in our minds)

I think the zip archive should work fine. Another option is removing the first block from the tarball that contains the extra header with tail -c +1025, if we can expect that to be present consistently.

e.g.: tar xzf "$archive" || gunzip -c "$archive" | tail -c +1025 | tar xf -

[BillyONeal]

The build failures were fixed by #46016 so we will merge through them if this change is otherwise OK

[BillyONeal]

I think the zip archive should work fine. Another option is removing the first block from the tarball that contains the extra header with tail -c +1025, if we can expect that to be present consistently.

I think the zip is better because we don't really know how / if that metadata is setup

[trisk]

I think this ready for review, with the alteration to use the zip file instead of the tarball.

[trisk]

@LilyWangLL @BillyONeal any time to look at the current version of this?