Using gn on MacOS without depending on Xcode

[barracuda156]

@timniederhausen This is not an issue as such, since it is probably implemented already, just I am not aware of how to do that: could you say if it is possible to bypass Xcode altogether for builds on Darwin? I.e. use normal toolchain: compiler, binutils etc. (Without patching out every mention from sources manually.)

For the context, I wanna build v8 for Darwin ppc, and Xcode is archaic there (Apple’s support policy…), while all needed tools as such are supported in recent versions. Also, generally speaking, I would prefer not to depend on Xcode on currently supported archs either.

Following a standard procedure the build fails immediately, not finding Xcode-specific includes.

[skeyboy]

ninja: Entering directory out'
[1/2] LINK gn
FAILED: gn
clang++ -O3 -fdata-sections -ffunction-sections -Wl,-dead_strip -mmacosx-version-min=10.9 -pthread -o gn src/gn/gn_main.o base.a gn_lib.a
ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libc++.tbd' for architecture x86_64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
[2/2] LINK gn_unittests
FAILED: gn_unittests
clang++ -O3 -fdata-sections -ffunction-sections -Wl,-dead_strip -mmacosx-version-min=10.9 -pthread -o gn_unittests src/gn/action_target_generator_unittest.o src/gn/analyzer_unittest.o src/gn/args_unittest.o src/gn/builder_record_map_unittest.o src/gn/builder_unittest.o src/gn/bundle_data_unittest.o src/gn/c_include_iterator_unittest.o src/gn/command_format_unittest.o src/gn/commands_unittest.o src/gn/compile_commands_writer_unittest.o src/gn/config_unittest.o src/gn/config_values_extractors_unittest.o src/gn/escape_unittest.o src/gn/exec_process_unittest.o src/gn/filesystem_utils_unittest.o src/gn/file_writer_unittest.o src/gn/frameworks_utils_unittest.o src/gn/function_filter_unittest.o src/gn/function_filter_labels_unittest.o src/gn/function_foreach_unittest.o src/gn/function_forward_variables_from_unittest.o src/gn/function_get_label_info_unittest.o src/gn/function_get_path_info_unittest.o src/gn/function_get_target_outputs_unittest.o src/gn/function_label_matches_unittest.o src/gn/function_process_file_template_unittest.o src/gn/function_rebase_path_unittest.o src/gn/function_template_unittest.o src/gn/function_toolchain_unittest.o src/gn/function_write_file_unittest.o src/gn/functions_target_rust_unittest.o src/gn/functions_target_unittest.o src/gn/functions_unittest.o src/gn/hash_table_base_unittest.o src/gn/header_checker_unittest.o src/gn/input_conversion_unittest.o src/gn/json_project_writer_unittest.o src/gn/rust_project_writer_unittest.o src/gn/rust_project_writer_helpers_unittest.o src/gn/label_pattern_unittest.o src/gn/label_unittest.o src/gn/loader_unittest.o src/gn/metadata_unittest.o src/gn/metadata_walk_unittest.o src/gn/ninja_action_target_writer_unittest.o src/gn/ninja_binary_target_writer_unittest.o src/gn/ninja_build_writer_unittest.o src/gn/ninja_bundle_data_target_writer_unittest.o src/gn/ninja_c_binary_target_writer_unittest.o src/gn/ninja_copy_target_writer_unittest.o src/gn/ninja_create_bundle_target_writer_unittest.o src/gn/ninja_generated_file_target_writer_unittest.o src/gn/ninja_group_target_writer_unittest.o src/gn/ninja_outputs_writer_unittest.o src/gn/ninja_rust_binary_target_writer_unittest.o src/gn/ninja_target_command_util_unittest.o src/gn/ninja_target_writer_unittest.o src/gn/ninja_toolchain_writer_unittest.o src/gn/operators_unittest.o src/gn/output_conversion_unittest.o src/gn/parse_tree_unittest.o src/gn/parser_unittest.o src/gn/path_output_unittest.o src/gn/pattern_unittest.o src/gn/pointer_set_unittest.o src/gn/resolved_target_data_unittest.o src/gn/resolved_target_deps_unittest.o src/gn/runtime_deps_unittest.o src/gn/scope_per_file_provider_unittest.o src/gn/scope_unittest.o src/gn/setup_unittest.o src/gn/source_dir_unittest.o src/gn/source_file_unittest.o src/gn/string_atom_unittest.o src/gn/string_output_buffer_unittest.o src/gn/string_utils_unittest.o src/gn/substitution_pattern_unittest.o src/gn/substitution_writer_unittest.o src/gn/target_public_pair_unittest.o src/gn/target_unittest.o src/gn/template_unittest.o src/gn/test_with_scheduler.o src/gn/test_with_scope.o src/gn/tokenizer_unittest.o src/gn/unique_vector_unittest.o src/gn/value_unittest.o src/gn/vector_utils_unittest.o src/gn/version_unittest.o src/gn/visibility_unittest.o src/gn/visual_studio_utils_unittest.o src/gn/visual_studio_writer_unittest.o src/gn/xcode_object_unittest.o src/gn/xml_element_writer_unittest.o src/util/atomic_write_unittest.o src/util/test/gn_test.o base.a gn_lib.a
ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libSystem.tbd' for architecture x86_64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.`

The CommandLineTools SDK is :

MacOSX14.sdk MacOSX14.4.sdk MacOSX13.sdk MacOSX13.3.sdk MacOSX.sdk

Who can help me ?

[barracuda156]

@skeyboy I have no idea about clang toolchain, but at least it is probably worth trying to get rid of -mmacosx-version-min=10.9 (when building for 13) and use LLVM clang with libtapi installed instead of an Apple one.

[timniederhausen]

ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libSystem.tbd' for architecture x86_64 clang++: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed.`

The CommandLineTools SDK is :

MacOSX14.sdk MacOSX14.4.sdk MacOSX13.sdk MacOSX13.3.sdk MacOSX.sdk

Who can help me ?

I can't reproduce that, even with exactly the same SDKs installed. Are you sure your environment is set up correctly? A quick search shows that this error is usually caused by mismatching compiler / linker and SDK versions. What's the output of which clang and which ld? Have you tried re-installing the command-line tools?

Also, this issue is originally for something else.
If the error persists and only affects building GN, please go ahead and open a new issue.

@timniederhausen This is not an issue as such, since it is probably implemented already, just I am not aware of how to do that: could you say if it is possible to bypass Xcode altogether for builds on Darwin? I.e. use normal toolchain: compiler, binutils etc. (Without patching out every mention from sources manually.)

For the context, I wanna build v8 for Darwin ppc, and Xcode is archaic there (Apple’s support policy…), while all needed tools as such are supported in recent versions. Also, generally speaking, I would prefer not to depend on Xcode on currently supported archs either.

Following a standard procedure the build fails immediately, not finding Xcode-specific includes.

It's an interesting idea but I unfortunately don't have the time to work on this.
Still, what xcode-specific headers were missing?

[barracuda156]

@timniederhausen That was a while ago, I don’t remember specifics, unfortunately.

I found a way to build V8 with CMake, and kinda fixed the build for ppc, but the source needs some fixes to assembler code, I think, I had weird linking errors when tried to use the resulting library.

It got stalled at that. I know when it got completely broken in upstream, but the problem is that we do not know if it ever worked at all: the early port was for AIX and ages ago, that code is not really usable now, sources changed too much, Darwin was always broken, for Linux there was an attempt to fix it, but half-merged and dropped. From the publicly available patches I think it could not have worked on ppc (or extra fixes were not shared).
So there is no reference point, unlike in most other cases, where ppc was supported historically but then either dropped or just bitrotten. And then I would need to handle both non-trivial assembler and V8 code structure, which I do not know. Finding time for this is problematic.