The NativeScript target carries two linker/compiler flags that Apple has already retired. One of them is on a deprecation clock and will become a hard build failure.
-ld_classic
OTHER_LDFLAGS on the NativeScript target, both Debug and Release (v8ios.xcodeproj/project.pbxproj:2899 and :2992). Every link emits:
ld: warning: -ld_classic is deprecated and will be removed in a future release
It forces the old linker. Apple has said it is going away; when it does, this stops being a warning and starts failing the build.
It was added in bb364f9 ("feat(visionos): support for xros platform", #235), so it was most likely a workaround for a new-linker bug on xros at that time rather than something iOS ever needed. Whatever that bug was, it is worth re-testing against a current Xcode.
-fembed-bitcode
OTHER_CFLAGS on the same two configurations (:2896, :2989). Bitcode was deprecated in Xcode 14 and App Store submission has not accepted it for years. The flag is dead weight.
What needs doing
Remove both, then confirm the framework still links on every slice — arm64-iphoneos, arm64-iphonesimulator, x86_64-iphonesimulator, arm64-maccatalyst, x86_64-maccatalyst, arm64-xros, arm64-xrsimulator. visionOS is the one that matters: it is the platform -ld_classic was introduced for, so if anything regresses it will be there, and a build that only checks iOS proves nothing.
If visionOS does still need the classic linker, the flag should at minimum be narrowed to the visionOS configurations only and carry a comment saying what breaks without it, so the next person is not left guessing.
Not to be confused with
The same links also emit ~174 copies of:
ld: warning: direct access in function '...' from file 'libv8_base_without_compiler.a(...)'
to global weak symbol 'std::__1::piecewise_construct' from file '...ModuleInternalCallbacks.o'
means the weak symbol cannot be overridden at runtime.
Those are benign and out of scope here. V8 is built with chromium's default -fvisibility=hidden while the framework's own translation units use Xcode's default visibility, so both sides emit the same libc++ weak symbol and V8's objects bind to ours directly. The symbol is an empty tag struct used only for compile-time dispatch:
struct _LIBCPP_TEMPLATE_VIS piecewise_construct_t { explicit piecewise_construct_t() = default; };
inline constexpr piecewise_construct_t piecewise_construct = piecewise_construct_t();It has no state and its address is never compared, so duplicate definitions are indistinguishable. The warning matters for typeinfo/vtable symbols (breaks dynamic_cast and cross-boundary catch) or operator new/delete (breaks allocator replacement) — a classification of a full Release-iphoneos link found all 174 to be the one tag constant and none of those. Matching visibility would silence them, but the framework has no EXPORTED_SYMBOLS_FILE, so -fvisibility=hidden would also hide the ObjC class symbols the public API needs.
The
NativeScripttarget carries two linker/compiler flags that Apple has already retired. One of them is on a deprecation clock and will become a hard build failure.-ld_classicOTHER_LDFLAGSon theNativeScripttarget, bothDebugandRelease(v8ios.xcodeproj/project.pbxproj:2899and:2992). Every link emits:It forces the old linker. Apple has said it is going away; when it does, this stops being a warning and starts failing the build.
It was added in bb364f9 ("feat(visionos): support for xros platform", #235), so it was most likely a workaround for a new-linker bug on
xrosat that time rather than something iOS ever needed. Whatever that bug was, it is worth re-testing against a current Xcode.-fembed-bitcodeOTHER_CFLAGSon the same two configurations (:2896,:2989). Bitcode was deprecated in Xcode 14 and App Store submission has not accepted it for years. The flag is dead weight.What needs doing
Remove both, then confirm the framework still links on every slice —
arm64-iphoneos,arm64-iphonesimulator,x86_64-iphonesimulator,arm64-maccatalyst,x86_64-maccatalyst,arm64-xros,arm64-xrsimulator. visionOS is the one that matters: it is the platform-ld_classicwas introduced for, so if anything regresses it will be there, and a build that only checks iOS proves nothing.If visionOS does still need the classic linker, the flag should at minimum be narrowed to the visionOS configurations only and carry a comment saying what breaks without it, so the next person is not left guessing.
Not to be confused with
The same links also emit ~174 copies of:
Those are benign and out of scope here. V8 is built with chromium's default
-fvisibility=hiddenwhile the framework's own translation units use Xcode's default visibility, so both sides emit the same libc++ weak symbol and V8's objects bind to ours directly. The symbol is an empty tag struct used only for compile-time dispatch:It has no state and its address is never compared, so duplicate definitions are indistinguishable. The warning matters for
typeinfo/vtablesymbols (breaksdynamic_castand cross-boundarycatch) oroperator new/delete(breaks allocator replacement) — a classification of a fullRelease-iphoneoslink found all 174 to be the one tag constant and none of those. Matching visibility would silence them, but the framework has noEXPORTED_SYMBOLS_FILE, so-fvisibility=hiddenwould also hide the ObjC class symbols the public API needs.