TAPI 1500.0.12.3 source has been published

[dpogue]

See https://github.com/apple-oss-distributions/tapi/tree/tapi-1500.0.12.3

1400.0.11 is also available https://github.com/apple-oss-distributions/tapi/tree/tapi-1400.0.11

[Un1q32]

TAPI 1600.0.11.8 sources have been released.

[zaryc89]

so i was feeling adventurous and tried:

git remote add -f libtapi-oss path/to/apple-libtapi-oss.git
git remote update
git diff 1300.6.5 tapi-1600.0.11.8

and i almost fainted by how long the differences are. its 5 am now.
i'm guessing i can't just "copy and paste" the new tapi branch in the src/tapi location.

[tpoechtrager]

Merging TAPI isn't easy... It also requires updating LLVM and applying patches/changes again. That's why I haven't done it so far.
Is there anything important missing in 1300.6.5?

[Un1q32]

so i was feeling adventurous and tried:

git remote add -f libtapi-oss path/to/apple-libtapi-oss.git git remote update git diff 1300.6.5 tapi-1600.0.11.8

and i almost fainted by how long the differences are. its 5 am now. i'm guessing i can't just "copy and paste" the new tapi branch in the src/tapi location.

A better strategy would be to diff this repo's tapi with Apple's tapi 1300 (https://github.com/apple-oss-distributions/tapi), and diff this repo's LLVM with https://github.com/swiftlang/llvm-project/tree/apple/stable/20210107, then apply those changes to tapi 1600 and https://github.com/swiftlang/llvm-project/releases/tag/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-07-02-a

[Un1q32]

Merging TAPI isn't easy... It also requires updating LLVM and applying patches/changes again. That's why I haven't done it so far.

Maybe change the repo to include apple llvm/api as submodules and apply some patches before actually building. Might make updating easier.

Is there anything important missing in 1300.6.5?

I don't think there's anything too massive, I can still use the latest macOS SDK with ld64 linked with tapi 1300. I'm the kind of person who can't stand having an old version number though, I might try to update it myself later, I think I've tried before and failed but another try couldn't hurt.

[Un1q32]

I might try to update it myself later

Progress update: the build is including incompatible .inc files from my host system's LLVM installation. Not sure how to make it build its own .inc files. I think if I solved that issue it would be basically done.

[tpoechtrager]

Porting/building TAPI is a mess... You are only building TAPI not the whole LLVM tree right?

[tpoechtrager]

I was able to successfully build TAPI 1600.0.11.8 by first building the clangBasic and vt_gen targets, then libtapi. What a mess. Also had to remove a lot of cmake stuff in order to make it build.

[tpoechtrager]

I added the 1600.0.11.8 sources.

x86_64h is kind of broken now, like a fallback to x86_64 is missing. Not sure if it is the TAPI library or the linker that's at fault.
Everything seems to work. Would be really interesting to know if x86_64h is also broken in Xcode.
Too bad I don't own a single Apple macOS device...

$ xcrun clang oclang/test.c -arch x86_64h
Undefined symbols for architecture x86_64h:
  "_printf", referenced from:
      _main in test-8eeb7a.o
ld: symbol(s) not found for architecture x86_64h
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[Un1q32]

You are only building TAPI not the whole LLVM tree right?

I replaced the llvm, clang, and tapi sources with tapi 1600 and the llvm commit that the tapi readme said to use. Also had to add the LLVM cmake stuff which gets it's own folder now. Only change I made to the build.sh script was removing the include fix, since the directories it was including don't exist in the newer LLVM sources. Building vt_gen along with clangBasic did the trick for me too.

Too bad I don't own a single Apple macOS device

I own 5 but one runs Linux, two run 10.5, one runs 10.6, the last is a haswell iMac I could probobly make run the latest macOS with OCLP, I'll do that and test. Maybe you should setup CI with a macOS github runner, github gives unlimited minutes to public repos now. You could easily compare the behavior of the ports with the Xcode versions.

[Un1q32]

Building vt_gen along with clangBasic did the trick for me too.

Oop, ld64 fails to link with it. I'll try your version.

[Un1q32]

Your version worked, can confirm x86_64h isn't working, I'm installing macOS 14 on my iMac now.

[Un1q32]

x86_64h is not broken with Xcode 16.2.

[Un1q32]

You forgot to remove -DCMAKE_CXX_FLAGS="$INCLUDE_FIX" by the way

[Un1q32]

Replacing the Xcode libtapi.dylib with one built from the unmodified open source release of tapi 1600 results in the same issue with x86_64h