Remove the deprecated -ld_classic and -fembed-bitcode flags from the NativeScript target

Ouvrez v8ios.xcodeproj/project.pbxproj et inspectez les entrées OTHER_LDFLAGS et OTHER_CFLAGS de la target NativeScript pour Debug et Release aux lignes référencées. Supprimez les flags obsolètes, puis compilez et liez chaque slice iOS, simulateur, Mac Catalyst et visionOS listée ; le travail est terminé lorsque tous les slices réussissent, ou lorsqu’une exception propre à visionOS est strictement circonscrite et documentée.

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 bb364f95 ("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.