node/node.gyp

1515 lines
45 KiB
Plaintext
Raw Normal View History

2011-08-04 00:01:30 +00:00
{
2011-08-04 06:36:27 +00:00
'variables': {
'v8_use_siphash%': 0,
'v8_trace_maps%': 0,
'v8_enable_pointer_compression%': 0,
'v8_enable_31bit_smis_on_64bit_arch%': 0,
'node_no_browser_globals%': 'false',
'node_snapshot_main%': '',
'node_use_node_snapshot%': 'false',
'node_use_v8_platform%': 'true',
'node_use_bundled_v8%': 'true',
'node_shared%': 'false',
'node_write_snapshot_as_string_literals': 'true',
'force_dynamic_crt%': 0,
'ossfuzz' : 'false',
'node_module_version%': '',
'node_use_amaro%': 'true',
'node_shared_brotli%': 'false',
2012-02-26 23:02:21 +00:00
'node_shared_zlib%': 'false',
'node_shared_http_parser%': 'false',
'node_shared_cares%': 'false',
'node_shared_libuv%': 'false',
'node_shared_sqlite%': 'false',
'node_shared_uvwasi%': 'false',
'node_shared_nghttp2%': 'false',
2011-09-04 23:01:53 +00:00
'node_use_openssl%': 'true',
'node_shared_openssl%': 'false',
'node_v8_options%': '',
'node_enable_v8_vtunejit%': 'false',
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
'node_core_target_name%': 'node',
'node_lib_target_name%': 'libnode',
'node_intermediate_lib_type%': 'static_library',
'node_builtin_modules_path%': '',
'linked_module_files': [
],
# We list the deps/ files out instead of globbing them in js2c.cc since we
# only include a subset of all the files under these directories.
# The lengths of their file names combined should not exceed the
# Windows command length limit or there would be an error.
# See https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation
2011-09-04 23:01:53 +00:00
'library_files': [
'<@(node_library_files)',
'<@(linked_module_files)',
],
'deps_files': [
'deps/v8/tools/splaytree.mjs',
'deps/v8/tools/codemap.mjs',
'deps/v8/tools/consarray.mjs',
'deps/v8/tools/csvparser.mjs',
'deps/v8/tools/profile.mjs',
'deps/v8/tools/profile_view.mjs',
'deps/v8/tools/logreader.mjs',
'deps/v8/tools/arguments.mjs',
'deps/v8/tools/tickprocessor.mjs',
'deps/v8/tools/sourcemap.mjs',
'deps/v8/tools/tickprocessor-driver.mjs',
'deps/acorn/acorn/dist/acorn.js',
'deps/acorn/acorn-walk/dist/walk.js',
'deps/minimatch/index.js',
'<@(node_builtin_shareable_builtins)',
2011-09-04 23:01:53 +00:00
],
'node_sources': [
'src/api/async_resource.cc',
'src/api/callback.cc',
'src/api/embed_helpers.cc',
'src/api/encoding.cc',
'src/api/environment.cc',
'src/api/exceptions.cc',
'src/api/hooks.cc',
'src/api/utils.cc',
'src/async_context_frame.cc',
'src/async_wrap.cc',
'src/base_object.cc',
'src/cares_wrap.cc',
'src/cleanup_queue.cc',
module: implement NODE_COMPILE_CACHE for automatic on-disk code caching This patch implements automatic on-disk code caching that can be enabled via an environment variable NODE_COMPILE_CACHE. When set, whenever Node.js compiles a CommonJS or a ECMAScript Module, it will use on-disk [V8 code cache][] persisted in the specified directory to speed up the compilation. This may slow down the first load of a module graph, but subsequent loads of the same module graph may get a significant speedup if the contents of the modules do not change. Locally, this speeds up loading of test/fixtures/snapshot/typescript.js from ~130ms to ~80ms. To clean up the generated code cache, simply remove the directory. It will be recreated the next time the same directory is used for `NODE_COMPILE_CACHE`. Compilation cache generated by one version of Node.js may not be used by a different version of Node.js. Cache generated by different versions of Node.js will be stored separately if the same directory is used to persist the cache, so they can co-exist. Caveat: currently when using this with V8 JavaScript code coverage, the coverage being collected by V8 may be less precise in functions that are deserialized from the code cache. It's recommended to turn this off when running tests to generate precise coverage. Implementation details: There is one cache file per module on disk. The directory layout is: - Compile cache directory (from NODE_COMPILE_CACHE) - 8b23c8fe: CRC32 hash of CachedDataVersionTag + NODE_VERESION - 2ea3424d: - 10860e5a: CRC32 hash of filename + module type - 431e9adc: ... - ... Inside the cache file, there is a header followed by the actual cache content: ``` [uint32_t] code size [uint32_t] code hash [uint32_t] cache size [uint32_t] cache hash ... compile cache content ... ``` When reading the cache file, we'll also check if the code size and code hash match the code that the module loader is loading and whether the cache size and cache hash match the file content read. If they don't match, or if V8 rejects the cache passed, we'll ignore the mismatch cache, and regenerate the cache after compilation succeeds and rewrite it to disk. PR-URL: https://github.com/nodejs/node/pull/52535 Refs: https://github.com/nodejs/node/issues/47472 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
2024-02-29 01:09:16 +00:00
'src/compile_cache.cc',
'src/connect_wrap.cc',
'src/connection_wrap.cc',
'src/dataqueue/queue.cc',
'src/debug_utils.cc',
build: encode non-ASCII Latin1 characters as one byte in JS2C Previously we had two encodings for JS files: 1. If a file contains only ASCII characters, encode it as a one-byte string (interpreted as uint8_t array during loading). 2. If a file contains any characters with code point above 127, encode it as a two-byte string (interpreted as uint16_t array during loading). This was done because V8 only supports Latin-1 and UTF16 encoding as underlying representation for strings. To store the JS code as external strings to save encoding cost and memory overhead we need to follow the representations supported by V8. Notice that there is a gap in the Latin1 range (128-255) that we encoded as two-byte, which was an undocumented TODO for a long time. That was fine previously because then files that contained code points beyond the 0-127 range contained code points >255. Now we have undici which contains code points in the range 0-255 (minus a replaceable code point >255). So this patch adds handling for the 128-255 range to reduce the size overhead caused by encoding them as two-byte. This could reduce the size of the binary by ~500KB and helps future files with this kind of code points. Drive-by: replace `’` with `'` in undici.js to make it a Latin-1 only string. That could be removed if undici updates itself to replace this character in the comment. PR-URL: https://github.com/nodejs/node/pull/51605 Reviewed-By: Daniel Lemire <daniel@lemire.me> Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
2024-02-17 17:09:24 +00:00
'src/embedded_data.cc',
'src/encoding_binding.cc',
'src/env.cc',
'src/fs_event_wrap.cc',
'src/handle_wrap.cc',
'src/heap_utils.cc',
'src/histogram.cc',
v8: implement v8.queryObjects() for memory leak regression testing This is similar to the `queryObjects()` console API provided by the Chromium DevTools console. It can be used to search for objects that have the matching constructor on its prototype chain in the entire heap, which can be useful for memory leak regression tests. To avoid surprising results, users should avoid using this API on constructors whose implementation they don't control, or on constructors that can be invoked by other parties in the application. To avoid accidental leaks, this API does not return raw references to the objects found. By default, it returns the count of the objects found. If `options.format` is `'summary'`, it returns an array containing brief string representations for each object. The visibility provided in this API is similar to what the heap snapshot provides, while users can save the cost of serialization and parsing and directly filer the target objects during the search. We have been using this API internally for the test suite, which has been more stable than any other leak regression testing strategies in the CI. With a public implementation we can now use the public API instead. PR-URL: https://github.com/nodejs/node/pull/51927 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
2024-03-02 22:11:30 +00:00
'src/internal_only_v8.cc',
'src/js_native_api.h',
'src/js_native_api_types.h',
'src/js_native_api_v8.cc',
'src/js_native_api_v8.h',
'src/js_native_api_v8_internals.h',
'src/js_stream.cc',
'src/json_utils.cc',
'src/js_udp_wrap.cc',
'src/json_parser.h',
'src/json_parser.cc',
'src/module_wrap.cc',
'src/node.cc',
'src/node_api.cc',
'src/node_binding.cc',
'src/node_blob.cc',
'src/node_buffer.cc',
'src/node_builtins.cc',
'src/node_config.cc',
'src/node_constants.cc',
'src/node_contextify.cc',
'src/node_credentials.cc',
'src/node_debug.cc',
'src/node_dir.cc',
'src/node_dotenv.cc',
'src/node_env_var.cc',
'src/node_errors.cc',
'src/node_external_reference.cc',
'src/node_file.cc',
'src/node_http_parser.cc',
'src/node_http2.cc',
'src/node_i18n.cc',
'src/node_main_instance.cc',
'src/node_messaging.cc',
'src/node_metadata.cc',
'src/node_modules.cc',
'src/node_options.cc',
'src/node_os.cc',
'src/node_perf.cc',
'src/node_platform.cc',
'src/node_postmortem_metadata.cc',
'src/node_process_events.cc',
'src/node_process_methods.cc',
'src/node_process_object.cc',
'src/node_realm.cc',
'src/node_report.cc',
'src/node_report_module.cc',
'src/node_report_utils.cc',
'src/node_sea.cc',
'src/node_serdes.cc',
'src/node_shadow_realm.cc',
'src/node_snapshotable.cc',
'src/node_sockaddr.cc',
'src/node_sqlite.cc',
'src/node_stat_watcher.cc',
'src/node_symbols.cc',
'src/node_task_queue.cc',
'src/node_task_runner.cc',
'src/node_trace_events.cc',
'src/node_types.cc',
'src/node_url.cc',
'src/node_util.cc',
'src/node_v8.cc',
'src/node_wasi.cc',
'src/node_wasm_web_api.cc',
'src/node_watchdog.cc',
'src/node_webstorage.cc',
'src/node_worker.cc',
'src/node_zlib.cc',
'src/path.cc',
'src/permission/child_process_permission.cc',
'src/permission/fs_permission.cc',
'src/permission/inspector_permission.cc',
'src/permission/permission.cc',
'src/permission/wasi_permission.cc',
'src/permission/worker_permission.cc',
'src/pipe_wrap.cc',
'src/process_wrap.cc',
'src/signal_wrap.cc',
'src/spawn_sync.cc',
'src/stream_base.cc',
'src/stream_pipe.cc',
'src/stream_wrap.cc',
'src/string_bytes.cc',
'src/string_decoder.cc',
'src/tcp_wrap.cc',
'src/timers.cc',
'src/timer_wrap.cc',
'src/tracing/agent.cc',
'src/tracing/node_trace_buffer.cc',
'src/tracing/node_trace_writer.cc',
'src/tracing/trace_event.cc',
'src/tracing/traced_value.cc',
'src/tty_wrap.cc',
'src/udp_wrap.cc',
'src/util.cc',
'src/uv.cc',
# headers to make for a more pleasant IDE experience
'src/aliased_buffer.h',
'src/aliased_buffer-inl.h',
'src/aliased_struct.h',
'src/aliased_struct-inl.h',
'src/async_context_frame.h',
'src/async_wrap.h',
'src/async_wrap-inl.h',
'src/base_object.h',
'src/base_object-inl.h',
'src/base_object_types.h',
'src/blob_serializer_deserializer.h',
'src/blob_serializer_deserializer-inl.h',
'src/callback_queue.h',
'src/callback_queue-inl.h',
'src/cleanup_queue.h',
'src/cleanup_queue-inl.h',
module: implement NODE_COMPILE_CACHE for automatic on-disk code caching This patch implements automatic on-disk code caching that can be enabled via an environment variable NODE_COMPILE_CACHE. When set, whenever Node.js compiles a CommonJS or a ECMAScript Module, it will use on-disk [V8 code cache][] persisted in the specified directory to speed up the compilation. This may slow down the first load of a module graph, but subsequent loads of the same module graph may get a significant speedup if the contents of the modules do not change. Locally, this speeds up loading of test/fixtures/snapshot/typescript.js from ~130ms to ~80ms. To clean up the generated code cache, simply remove the directory. It will be recreated the next time the same directory is used for `NODE_COMPILE_CACHE`. Compilation cache generated by one version of Node.js may not be used by a different version of Node.js. Cache generated by different versions of Node.js will be stored separately if the same directory is used to persist the cache, so they can co-exist. Caveat: currently when using this with V8 JavaScript code coverage, the coverage being collected by V8 may be less precise in functions that are deserialized from the code cache. It's recommended to turn this off when running tests to generate precise coverage. Implementation details: There is one cache file per module on disk. The directory layout is: - Compile cache directory (from NODE_COMPILE_CACHE) - 8b23c8fe: CRC32 hash of CachedDataVersionTag + NODE_VERESION - 2ea3424d: - 10860e5a: CRC32 hash of filename + module type - 431e9adc: ... - ... Inside the cache file, there is a header followed by the actual cache content: ``` [uint32_t] code size [uint32_t] code hash [uint32_t] cache size [uint32_t] cache hash ... compile cache content ... ``` When reading the cache file, we'll also check if the code size and code hash match the code that the module loader is loading and whether the cache size and cache hash match the file content read. If they don't match, or if V8 rejects the cache passed, we'll ignore the mismatch cache, and regenerate the cache after compilation succeeds and rewrite it to disk. PR-URL: https://github.com/nodejs/node/pull/52535 Refs: https://github.com/nodejs/node/issues/47472 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
2024-02-29 01:09:16 +00:00
'src/compile_cache.h',
'src/connect_wrap.h',
'src/connection_wrap.h',
'src/cppgc_helpers.h',
'src/dataqueue/queue.h',
'src/debug_utils.h',
'src/debug_utils-inl.h',
'src/embedded_data.h',
'src/encoding_binding.h',
'src/env_properties.h',
'src/env.h',
'src/env-inl.h',
'src/handle_wrap.h',
'src/histogram.h',
'src/histogram-inl.h',
'src/js_stream.h',
'src/json_utils.h',
'src/large_pages/node_large_page.cc',
'src/large_pages/node_large_page.h',
'src/memory_tracker.h',
'src/memory_tracker-inl.h',
'src/module_wrap.h',
'src/node.h',
'src/node_api.h',
'src/node_api_types.h',
'src/node_binding.h',
'src/node_blob.h',
'src/node_buffer.h',
'src/node_builtins.h',
'src/node_constants.h',
'src/node_context_data.h',
'src/node_contextify.h',
'src/node_debug.h',
'src/node_dir.h',
'src/node_dotenv.h',
'src/node_errors.h',
'src/node_exit_code.h',
'src/node_external_reference.h',
'src/node_file.h',
'src/node_file-inl.h',
'src/node_http_common.h',
'src/node_http_common-inl.h',
'src/node_http2.h',
'src/node_http2_state.h',
'src/node_i18n.h',
'src/node_internals.h',
'src/node_main_instance.h',
'src/node_mem.h',
'src/node_mem-inl.h',
'src/node_messaging.h',
'src/node_metadata.h',
'src/node_mutex.h',
'src/node_modules.h',
'src/node_object_wrap.h',
'src/node_options.h',
'src/node_options-inl.h',
'src/node_perf.h',
'src/node_perf_common.h',
'src/node_platform.h',
'src/node_process.h',
'src/node_process-inl.h',
'src/node_realm.h',
'src/node_realm-inl.h',
'src/node_report.h',
'src/node_revert.h',
'src/node_root_certs.h',
'src/node_sea.h',
'src/node_shadow_realm.h',
'src/node_snapshotable.h',
'src/node_snapshot_builder.h',
'src/node_sockaddr.h',
'src/node_sockaddr-inl.h',
'src/node_sqlite.h',
'src/node_stat_watcher.h',
'src/node_union_bytes.h',
'src/node_url.h',
'src/node_version.h',
'src/node_v8.h',
'src/node_v8_platform-inl.h',
'src/node_wasi.h',
'src/node_watchdog.h',
'src/node_webstorage.h',
'src/node_worker.h',
'src/path.h',
'src/permission/child_process_permission.h',
'src/permission/fs_permission.h',
'src/permission/inspector_permission.h',
'src/permission/permission.h',
'src/permission/wasi_permission.h',
'src/permission/worker_permission.h',
'src/pipe_wrap.h',
'src/req_wrap.h',
'src/req_wrap-inl.h',
'src/spawn_sync.h',
'src/stream_base.h',
'src/stream_base-inl.h',
'src/stream_pipe.h',
'src/stream_wrap.h',
'src/string_bytes.h',
'src/string_decoder.h',
'src/string_decoder-inl.h',
'src/tcp_wrap.h',
'src/timers.h',
'src/tracing/agent.h',
'src/tracing/node_trace_buffer.h',
'src/tracing/node_trace_writer.h',
'src/tracing/trace_event.h',
'src/tracing/trace_event_common.h',
'src/tracing/traced_value.h',
'src/timer_wrap.h',
'src/timer_wrap-inl.h',
'src/tty_wrap.h',
'src/udp_wrap.h',
'src/util.h',
'src/util-inl.h',
],
'node_crypto_sources': [
'src/crypto/crypto_aes.cc',
'src/crypto/crypto_bio.cc',
'src/crypto/crypto_common.cc',
'src/crypto/crypto_dsa.cc',
'src/crypto/crypto_hkdf.cc',
'src/crypto/crypto_pbkdf2.cc',
'src/crypto/crypto_sig.cc',
'src/crypto/crypto_timing.cc',
'src/crypto/crypto_cipher.cc',
'src/crypto/crypto_context.cc',
'src/crypto/crypto_ec.cc',
'src/crypto/crypto_hmac.cc',
'src/crypto/crypto_random.cc',
'src/crypto/crypto_rsa.cc',
'src/crypto/crypto_spkac.cc',
'src/crypto/crypto_util.cc',
'src/crypto/crypto_clienthello.cc',
'src/crypto/crypto_dh.cc',
'src/crypto/crypto_hash.cc',
'src/crypto/crypto_keys.cc',
'src/crypto/crypto_keygen.cc',
'src/crypto/crypto_scrypt.cc',
'src/crypto/crypto_tls.cc',
'src/crypto/crypto_x509.cc',
'src/crypto/crypto_bio.h',
'src/crypto/crypto_clienthello-inl.h',
'src/crypto/crypto_dh.h',
'src/crypto/crypto_hmac.h',
'src/crypto/crypto_rsa.h',
'src/crypto/crypto_spkac.h',
'src/crypto/crypto_util.h',
'src/crypto/crypto_cipher.h',
'src/crypto/crypto_common.h',
'src/crypto/crypto_dsa.h',
'src/crypto/crypto_hash.h',
'src/crypto/crypto_keys.h',
'src/crypto/crypto_keygen.h',
'src/crypto/crypto_scrypt.h',
'src/crypto/crypto_tls.h',
'src/crypto/crypto_clienthello.h',
'src/crypto/crypto_context.h',
'src/crypto/crypto_ec.h',
'src/crypto/crypto_hkdf.h',
'src/crypto/crypto_pbkdf2.h',
'src/crypto/crypto_sig.h',
'src/crypto/crypto_random.h',
'src/crypto/crypto_timing.h',
'src/crypto/crypto_x509.h',
'src/node_crypto.cc',
'src/node_crypto.h',
],
'node_quic_sources': [
'src/quic/application.cc',
'src/quic/bindingdata.cc',
'src/quic/cid.cc',
'src/quic/data.cc',
'src/quic/endpoint.cc',
'src/quic/http3.cc',
'src/quic/logstream.cc',
'src/quic/packet.cc',
'src/quic/preferredaddress.cc',
'src/quic/session.cc',
'src/quic/sessionticket.cc',
'src/quic/streams.cc',
'src/quic/tlscontext.cc',
'src/quic/tokens.cc',
'src/quic/transportparams.cc',
'src/quic/application.h',
'src/quic/bindingdata.h',
'src/quic/cid.h',
'src/quic/data.h',
'src/quic/endpoint.h',
'src/quic/http3.h',
'src/quic/logstream.h',
'src/quic/packet.h',
'src/quic/preferredaddress.h',
'src/quic/session.h',
'src/quic/sessionticket.h',
'src/quic/streams.h',
'src/quic/tlscontext.h',
'src/quic/tokens.h',
'src/quic/transportparams.h',
'src/quic/quic.cc',
],
'node_cctest_sources': [
'src/node_snapshot_stub.cc',
'test/cctest/node_test_fixture.cc',
'test/cctest/node_test_fixture.h',
'test/cctest/test_aliased_buffer.cc',
'test/cctest/test_base64.cc',
'test/cctest/test_base_object_ptr.cc',
'test/cctest/test_cppgc.cc',
'test/cctest/test_node_postmortem_metadata.cc',
'test/cctest/test_node_task_runner.cc',
'test/cctest/test_environment.cc',
'test/cctest/test_linked_binding.cc',
'test/cctest/test_node_api.cc',
'test/cctest/test_path.cc',
'test/cctest/test_per_process.cc',
'test/cctest/test_platform.cc',
'test/cctest/test_report.cc',
'test/cctest/test_json_utils.cc',
'test/cctest/test_sockaddr.cc',
'test/cctest/test_traced_value.cc',
'test/cctest/test_util.cc',
'test/cctest/test_dataqueue.cc',
],
'node_cctest_openssl_sources': [
'test/cctest/test_crypto_clienthello.cc',
'test/cctest/test_node_crypto.cc',
'test/cctest/test_node_crypto_env.cc',
'test/cctest/test_quic_cid.cc',
'test/cctest/test_quic_error.cc',
'test/cctest/test_quic_tokens.cc',
],
'node_cctest_inspector_sources': [
'test/cctest/test_inspector_socket.cc',
'test/cctest/test_inspector_socket_server.cc',
],
'node_mksnapshot_exec': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)node_mksnapshot<(EXECUTABLE_SUFFIX)',
'node_js2c_exec': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)node_js2c<(EXECUTABLE_SUFFIX)',
'conditions': [
['GENERATOR == "ninja"', {
'node_text_start_object_path': 'src/large_pages/node_text_start.node_text_start.o'
}, {
'node_text_start_object_path': 'node_text_start/src/large_pages/node_text_start.o'
}],
[ 'node_shared=="true"', {
'node_target_type%': 'shared_library',
'conditions': [
['OS in "aix os400"', {
# For AIX, always generate static library first,
# It needs an extra step to generate exp and
# then use both static lib and exp to create
# shared lib.
'node_intermediate_lib_type': 'static_library',
}, {
'node_intermediate_lib_type': 'shared_library',
}],
],
}, {
'node_target_type%': 'executable',
}],
[ 'OS=="win" and '
'node_use_openssl=="true" and '
'node_shared_openssl=="false"', {
'use_openssl_def%': 1,
}, {
'use_openssl_def%': 0,
}],
],
2011-08-04 06:36:27 +00:00
},
'target_defaults': {
# Putting these explicitly here so not to depend on `common.gypi`.
# `common.gypi` need to be more general because it is used to build userland native addons.
# Refs: https://github.com/nodejs/node-gyp/issues/1118
'cflags': [ '-Wall', '-Wextra', '-Wno-unused-parameter', ],
'xcode_settings': {
'WARNING_CFLAGS': [
'-Wall',
'-Wendif-labels',
'-W',
'-Wno-unused-parameter',
'-Werror=undefined-inline',
'-Werror=extra-semi',
],
},
'conditions': [
['clang==0 and OS!="win"', {
'cflags': [ '-Wno-restrict', ],
}],
# Pointer authentication for ARM64.
['target_arch=="arm64"', {
'target_conditions': [
['_toolset=="host"', {
'conditions': [
['host_arch=="arm64"', {
'cflags': ['-mbranch-protection=standard'],
}],
],
}],
['_toolset=="target"', {
'cflags': ['-mbranch-protection=standard'],
}],
],
}],
['OS in "aix os400"', {
'ldflags': [
'-Wl,-bnoerrmsg',
],
}],
['OS=="linux" and clang==1', {
'libraries': ['-latomic'],
}],
],
},
2011-08-04 00:01:30 +00:00
'targets': [
{
'target_name': 'node_text_start',
'type': 'none',
'conditions': [
[ 'OS in "linux freebsd solaris" and '
'target_arch=="x64"', {
'type': 'static_library',
'sources': [
'src/large_pages/node_text_start.S'
]
}],
]
},
2011-08-04 00:01:30 +00:00
{
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
'target_name': '<(node_core_target_name)',
'type': 'executable',
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'deps/v8/include',
'deps/postject'
],
'sources': [
'src/node_main.cc'
],
'dependencies': [
'deps/histogram/histogram.gyp:histogram',
],
'msvs_settings': {
'VCLinkerTool': {
'GenerateMapFile': 'true', # /MAP
'MapExports': 'true', # /MAPINFO:EXPORTS
'RandomizedBaseAddress': 2, # enable ASLR
'DataExecutionPrevention': 2, # enable DEP
'AllowIsolation': 'true',
# By default, the MSVC linker only reserves 1 MiB of stack memory for
# each thread, whereas other platforms typically allow much larger
# stack memory sections. We raise the limit to make it more consistent
# across platforms and to support the few use cases that require large
# amounts of stack memory, without having to modify the node binary.
'StackReserveSize': 0x800000,
},
},
# - "C4244: conversion from 'type1' to 'type2', possible loss of data"
# Ususaly safe. Disable for `dep`, enable for `src`
'msvs_disabled_warnings!': [4244],
'conditions': [
[ 'error_on_warn=="true"', {
'cflags': ['-Werror'],
'xcode_settings': {
'WARNING_CFLAGS': [ '-Werror' ],
},
}],
[ 'node_intermediate_lib_type=="static_library" and '
'node_shared=="true" and OS in "aix os400"', {
# For AIX, shared lib is linked by static lib and .exp. In the
# case here, the executable needs to link to shared lib.
# Therefore, use 'node_aix_shared' target to generate the
# shared lib and then executable.
'dependencies': [ 'node_aix_shared' ],
}, {
'dependencies': [ '<(node_lib_target_name)' ],
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'conditions': [
['OS=="win" and node_shared=="true"', {
'dependencies': ['generate_node_def'],
'msvs_settings': {
'VCLinkerTool': {
'ModuleDefinitionFile': '<(PRODUCT_DIR)/<(node_core_target_name).def',
},
},
}],
],
}],
[ 'node_intermediate_lib_type=="static_library" and node_shared=="false"', {
'xcode_settings': {
'OTHER_LDFLAGS': [
'-Wl,-force_load,<(PRODUCT_DIR)/<(STATIC_LIB_PREFIX)<(node_core_target_name)<(STATIC_LIB_SUFFIX)',
'-Wl,-force_load,<(PRODUCT_DIR)/<(STATIC_LIB_PREFIX)v8_base_without_compiler<(STATIC_LIB_SUFFIX)',
],
},
'msvs_settings': {
'VCLinkerTool': {
'AdditionalOptions': [
'/WHOLEARCHIVE:<(PRODUCT_DIR)/lib/<(node_lib_target_name)<(STATIC_LIB_SUFFIX)',
'/WHOLEARCHIVE:<(PRODUCT_DIR)/lib/<(STATIC_LIB_PREFIX)v8_base_without_compiler<(STATIC_LIB_SUFFIX)',
],
},
},
'conditions': [
['OS != "aix" and OS != "os400" and OS != "mac" and OS != "ios"', {
'ldflags': [
'-Wl,--whole-archive',
'<(obj_dir)/<(STATIC_LIB_PREFIX)<(node_core_target_name)<(STATIC_LIB_SUFFIX)',
'<(obj_dir)/tools/v8_gypfiles/<(STATIC_LIB_PREFIX)v8_base_without_compiler<(STATIC_LIB_SUFFIX)',
'-Wl,--no-whole-archive',
],
}],
[ 'OS=="win"', {
'sources': [ 'src/res/node.rc' ],
}],
],
}],
[ 'node_shared=="true"', {
'xcode_settings': {
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', '-Wl,-rpath,@loader_path/../lib'],
},
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'conditions': [
['OS=="linux"', {
'ldflags': [
'-Wl,-rpath,\\$$ORIGIN/../lib'
],
}],
],
}],
[ 'enable_lto=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [
# man ld -export_dynamic:
# Preserves all global symbols in main executables during LTO.
# Without this option, Link Time Optimization is allowed to
# inline and remove global functions. This option is used when
# a main executable may load a plug-in which requires certain
# symbols from the main executable.
'-Wl,-export_dynamic',
],
},
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
src: merge into core Make node-report part of core runtime because: 1. When enabled, node-report significantly helps root cause various types of problems, including support issues sent to the various repos of the Node.js organization. 2. The requirement of explicitly adding the dependency to node-report in user applications often represents a blocker to adoption. Major deviation from the module version of the node-report is that the report is generated in JSON format, as opposed to human readable text. No new functionalities have been added, changes that are required for melding it as a built-in capability has been affected on the module version of node-report (https://github.com/nodejs/node-report) Co-authored-by: Bidisha Pyne <bidipyne@in.ibm.com> Co-authored-by: Howard Hellyer <hhellyer@uk.ibm.com> Co-authored-by: Jeremiah Senkpiel <fishrock123@rocketmail.com> Co-authored-by: Julian Alimin <dmastag@yahoo.com> Co-authored-by: Lakshmi Swetha Gopireddy <lakshmigopireddy@in.ibm.com> Co-authored-by: Manusaporn Treerungroj <m.treerungroj@gmail.com> Co-authored-by: Michael Dawson <michael_dawson@ca.ibm.com> Co-authored-by: Richard Chamberlain <richard_chamberlain@uk.ibm.com> Co-authored-by: Richard Lau <riclau@uk.ibm.com> Co-authored-by: Sam Roberts <vieuxtech@gmail.com> Co-authored-by: Vipin Menon <vipinmv1@in.ibm.com> PR-URL: https://github.com/nodejs/node/pull/22712 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
2018-09-05 14:06:59 +00:00
],
}],
['node_with_ltcg=="true"', {
'msvs_settings': {
'VCCLCompilerTool': {
'WholeProgramOptimization': 'true' # /GL, whole program optimization, needed for LTCG
},
'VCLibrarianTool': {
'AdditionalOptions': [
'/LTCG:INCREMENTAL', # link time code generation
],
},
'VCLinkerTool': {
'OptimizeReferences': 2, # /OPT:REF
'EnableCOMDATFolding': 2, # /OPT:ICF
'LinkIncremental': 1, # disable incremental linking
'AdditionalOptions': [
'/LTCG:INCREMENTAL', # incremental link-time code generation
],
}
}
}, {
'msvs_settings': {
'VCCLCompilerTool': {
'WholeProgramOptimization': 'false'
},
'VCLinkerTool': {
'LinkIncremental': 2 # enable incremental linking
},
},
}],
['node_use_node_snapshot=="true"', {
'dependencies': [
'node_mksnapshot',
],
'conditions': [
['node_snapshot_main!=""', {
'actions': [
{
'action_name': 'node_mksnapshot',
'process_outputs_as_sources': 1,
'inputs': [
'<(node_mksnapshot_exec)',
'<(node_snapshot_main)',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_snapshot.cc',
],
'action': [
'<(node_mksnapshot_exec)',
'--build-snapshot',
'<(node_snapshot_main)',
'<@(_outputs)',
],
},
],
}, {
'actions': [
{
'action_name': 'node_mksnapshot',
'process_outputs_as_sources': 1,
'inputs': [
'<(node_mksnapshot_exec)',
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_snapshot.cc',
],
'action': [
'<@(_inputs)',
'<@(_outputs)',
],
},
],
}],
],
}, {
'sources': [
'src/node_snapshot_stub.cc'
],
}],
[ 'OS in "linux freebsd" and '
'target_arch=="x64"', {
'dependencies': [ 'node_text_start' ],
'ldflags+': [
'<(obj_dir)/<(node_text_start_object_path)'
]
}],
['node_fipsinstall=="true"', {
'variables': {
'openssl-cli': '<(PRODUCT_DIR)/<(EXECUTABLE_PREFIX)openssl-cli<(EXECUTABLE_SUFFIX)',
'provider_name': 'libopenssl-fipsmodule',
'opensslconfig': './deps/openssl/nodejs-openssl.cnf',
'conditions': [
['GENERATOR == "ninja"', {
'fipsmodule_internal': '<(PRODUCT_DIR)/lib/<(provider_name).so',
'fipsmodule': '<(PRODUCT_DIR)/obj/lib/openssl-modules/fips.so',
'fipsconfig': '<(PRODUCT_DIR)/obj/lib/fipsmodule.cnf',
'opensslconfig_internal': '<(PRODUCT_DIR)/obj/lib/openssl.cnf',
}, {
'fipsmodule_internal': '<(PRODUCT_DIR)/obj.target/deps/openssl/<(provider_name).so',
'fipsmodule': '<(PRODUCT_DIR)/obj.target/deps/openssl/lib/openssl-modules/fips.so',
'fipsconfig': '<(PRODUCT_DIR)/obj.target/deps/openssl/fipsmodule.cnf',
'opensslconfig_internal': '<(PRODUCT_DIR)/obj.target/deps/openssl/openssl.cnf',
}],
],
},
'actions': [
{
'action_name': 'fipsinstall',
'process_outputs_as_sources': 1,
'inputs': [
'<(fipsmodule_internal)',
],
'outputs': [
'<(fipsconfig)',
],
'action': [
'<(openssl-cli)', 'fipsinstall',
'-provider_name', '<(provider_name)',
'-module', '<(fipsmodule_internal)',
'-out', '<(fipsconfig)',
#'-quiet',
],
},
{
'action_name': 'copy_fips_module',
'inputs': [
'<(fipsmodule_internal)',
],
'outputs': [
'<(fipsmodule)',
],
'action': [
'<(python)', 'tools/copyfile.py',
'<(fipsmodule_internal)',
'<(fipsmodule)',
],
},
{
'action_name': 'copy_openssl_cnf_and_include_fips_cnf',
'inputs': [ '<(opensslconfig)', ],
'outputs': [ '<(opensslconfig_internal)', ],
'action': [
'<(python)', 'tools/enable_fips_include.py',
'<(opensslconfig)',
'<(opensslconfig_internal)',
'<(fipsconfig)',
],
},
],
}, {
'variables': {
'opensslconfig_internal': '<(obj_dir)/deps/openssl/openssl.cnf',
'opensslconfig': './deps/openssl/nodejs-openssl.cnf',
},
'actions': [
{
'action_name': 'reset_openssl_cnf',
'inputs': [ '<(opensslconfig)', ],
'outputs': [ '<(opensslconfig_internal)', ],
'action': [
'<(python)', 'tools/copyfile.py',
'<(opensslconfig)',
'<(opensslconfig_internal)',
],
},
],
}],
],
}, # node_core_target_name
{
'target_name': '<(node_lib_target_name)',
'type': '<(node_intermediate_lib_type)',
'includes': [
'node.gypi',
],
2011-08-04 23:40:07 +00:00
'include_dirs': [
2011-08-08 19:11:48 +00:00
'src',
'deps/postject',
'<(SHARED_INTERMEDIATE_DIR)' # for node_natives.h
2011-08-04 23:40:07 +00:00
],
'dependencies': [
'deps/googletest/googletest.gyp:gtest_prod',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
'deps/simdjson/simdjson.gyp:simdjson',
'deps/simdutf/simdutf.gyp:simdutf',
'deps/ada/ada.gyp:ada',
'deps/nbytes/nbytes.gyp:nbytes',
'node_js2c#host',
],
2011-08-04 23:40:07 +00:00
2011-08-04 00:01:30 +00:00
'sources': [
'<@(node_sources)',
# Dependency headers
'deps/v8/include/v8.h',
'deps/postject/postject-api.h',
2011-09-04 23:01:53 +00:00
# javascript files to make for an even more pleasant IDE experience
'<@(library_files)',
'<@(deps_files)',
# node.gyp is added by default, common.gypi is added for change detection
2011-10-28 10:10:24 +00:00
'common.gypi',
2011-08-04 23:40:07 +00:00
],
'variables': {
'openssl_system_ca_path%': '',
'openssl_default_cipher_list%': '',
},
'cflags': ['-Werror=unused-result'],
2011-08-04 23:40:07 +00:00
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
# Warn when using deprecated V8 APIs.
'V8_DEPRECATION_WARNINGS=1',
'NODE_OPENSSL_SYSTEM_CERT_PATH="<(openssl_system_ca_path)"',
2011-08-04 00:01:30 +00:00
],
# - "C4244: conversion from 'type1' to 'type2', possible loss of data"
# Ususaly safe. Disable for `dep`, enable for `src`
'msvs_disabled_warnings!': [4244],
'conditions': [
[ 'openssl_default_cipher_list!=""', {
'defines': [
'NODE_OPENSSL_DEFAULT_CIPHER_LIST="<(openssl_default_cipher_list)"'
]
}],
[ 'error_on_warn=="true"', {
'cflags': ['-Werror'],
'xcode_settings': {
'WARNING_CFLAGS': [ '-Werror' ],
},
}],
[ 'node_builtin_modules_path!=""', {
'defines': [ 'NODE_BUILTIN_MODULES_PATH="<(node_builtin_modules_path)"' ]
}],
[ 'node_shared=="true"', {
'sources': [
'src/node_snapshot_stub.cc',
]
}],
[ 'node_shared=="true" and node_module_version!="" and OS!="win"', {
'product_extension': '<(shlib_suffix)',
'xcode_settings': {
'LD_DYLIB_INSTALL_NAME':
'@rpath/lib<(node_core_target_name).<(shlib_suffix)'
},
}],
[ 'node_use_node_code_cache=="true"', {
'defines': [
'NODE_USE_NODE_CODE_CACHE=1',
],
}],
['node_shared=="true" and OS in "aix os400"', {
'product_name': 'node_base',
}],
[ 'v8_enable_inspector==1', {
'includes' : [ 'src/inspector/node_inspector.gypi' ],
}, {
'defines': [ 'HAVE_INSPECTOR=0' ]
}],
[ 'OS=="win"', {
'conditions': [
[ 'node_intermediate_lib_type!="static_library"', {
'sources': [
'src/res/node.rc',
],
}],
],
'libraries': [
'Dbghelp',
'Psapi',
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
'Winmm',
'Ws2_32',
],
}],
[ 'node_use_openssl=="true"', {
'sources': [
'<@(node_crypto_sources)',
'<@(node_quic_sources)',
],
'dependencies': [
'deps/ncrypto/ncrypto.gyp:ncrypto',
],
}],
[ 'OS in "linux freebsd mac solaris" and '
'target_arch=="x64" and '
'node_target_type=="executable"', {
'defines': [ 'NODE_ENABLE_LARGE_CODE_PAGES=1' ],
}],
[ 'use_openssl_def==1', {
# TODO(bnoordhuis) Make all platforms export the same list of symbols.
# Teach mkssldef.py to generate linker maps that UNIX linkers understand.
'variables': {
'mkssldef_flags': [
# Categories to export.
'-CAES,BF,BIO,DES,DH,DSA,EC,ECDH,ECDSA,ENGINE,EVP,HMAC,MD4,MD5,'
'PSK,RC2,RC4,RSA,SHA,SHA0,SHA1,SHA256,SHA512,SOCK,STDIO,TLSEXT,'
'UI,FP_API,TLS1_METHOD,TLS1_1_METHOD,TLS1_2_METHOD,SCRYPT,OCSP,'
'NEXTPROTONEG,RMD160,CAST,DEPRECATEDIN_1_1_0,DEPRECATEDIN_1_2_0,'
'DEPRECATEDIN_3_0',
# Defines.
'-DWIN32',
# Symbols to filter from the export list.
'-X^DSO',
'-X^_',
'-X^private_',
# Base generated DEF on zlib.def
'-Bdeps/zlib/win32/zlib.def'
],
},
'conditions': [
['openssl_is_fips!=""', {
'variables': { 'mkssldef_flags': ['-DOPENSSL_FIPS'] },
}],
],
'actions': [
{
'action_name': 'mkssldef',
'inputs': [
'deps/openssl/openssl/util/libcrypto.num',
'deps/openssl/openssl/util/libssl.num',
],
'outputs': ['<(SHARED_INTERMEDIATE_DIR)/openssl.def'],
'process_outputs_as_sources': 1,
'action': [
'<(python)',
'tools/mkssldef.py',
'<@(mkssldef_flags)',
'-o',
'<@(_outputs)',
'<@(_inputs)',
],
},
],
}],
[ 'debug_nghttp2==1', {
'defines': [ 'NODE_DEBUG_NGHTTP2=1' ]
}],
],
2011-08-04 00:01:30 +00:00
'actions': [
{
'action_name': 'node_js2c',
'process_outputs_as_sources': 1,
2011-08-04 00:01:30 +00:00
'inputs': [
'<(node_js2c_exec)',
2011-08-04 00:01:30 +00:00
'<@(library_files)',
'<@(deps_files)',
'config.gypi'
2011-08-04 00:01:30 +00:00
],
'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/node_javascript.cc',
2011-08-04 00:01:30 +00:00
],
'action': [
'<(node_js2c_exec)',
'<@(_outputs)',
'lib',
'config.gypi',
'<@(deps_files)',
'<@(linked_module_files)',
],
2011-08-04 00:01:30 +00:00
},
],
}, # node_lib_target_name
{ # fuzz_env
'target_name': 'fuzz_env',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/sqlite',
'test/cctest',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/fuzzers/fuzz_env.cc',
],
'conditions': [
['OS=="linux"', {
'ldflags': [ '-fsanitize=fuzzer' ]
}],
# Ensure that ossfuzz flag has been set and that we are on Linux
[ 'OS!="linux" or ossfuzz!="true"', {
'type': 'none',
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
],
}, # fuzz_env
{ # fuzz_ClientHelloParser.cc
'target_name': 'fuzz_ClientHelloParser',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
'deps/uvwasi/uvwasi.gyp:uvwasi',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/sqlite',
'deps/uv/include',
'deps/uvwasi/include',
'test/cctest',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/fuzzers/fuzz_ClientHelloParser.cc',
],
'conditions': [
['OS=="linux"', {
'ldflags': [ '-fsanitize=fuzzer' ]
}],
# Ensure that ossfuzz flag has been set and that we are on Linux
[ 'OS!="linux" or ossfuzz!="true"', {
'type': 'none',
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
],
}, # fuzz_ClientHelloParser.cc
{ # fuzz_strings
'target_name': 'fuzz_strings',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/googletest/googletest.gyp:gtest_prod',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
'deps/uvwasi/uvwasi.gyp:uvwasi',
'deps/ada/ada.gyp:ada',
'deps/nbytes/nbytes.gyp:nbytes',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/sqlite',
'deps/uv/include',
'deps/uvwasi/include',
'test/cctest',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/fuzzers/fuzz_strings.cc',
],
'conditions': [
['OS=="linux"', {
'ldflags': [ '-fsanitize=fuzzer' ]
}],
# Ensure that ossfuzz flag has been set and that we are on Linux
[ 'OS!="linux" or ossfuzz!="true"', {
'type': 'none',
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
],
}, # fuzz_strings
{
'target_name': 'cctest',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/googletest/googletest.gyp:gtest',
'deps/googletest/googletest.gyp:gtest_main',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
'deps/simdjson/simdjson.gyp:simdjson',
'deps/simdutf/simdutf.gyp:simdutf',
'deps/ada/ada.gyp:ada',
'deps/nbytes/nbytes.gyp:nbytes',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/sqlite',
'test/cctest',
],
'defines': [
'NODE_ARCH="<(target_arch)"',
'NODE_PLATFORM="<(OS)"',
'NODE_WANT_INTERNALS=1',
],
'sources': [ '<@(node_cctest_sources)' ],
'conditions': [
[ 'node_use_openssl=="true"', {
'defines': [
'HAVE_OPENSSL=1',
],
'dependencies': [
'deps/ncrypto/ncrypto.gyp:ncrypto',
],
'sources': [ '<@(node_cctest_openssl_sources)' ],
}],
['v8_enable_inspector==1', {
'defines': [
'HAVE_INSPECTOR=1',
],
'sources': [ '<@(node_cctest_inspector_sources)' ],
}, {
'defines': [
'HAVE_INSPECTOR=0',
]
}],
['OS=="solaris"', {
'ldflags': [ '-I<(SHARED_INTERMEDIATE_DIR)' ]
}],
# Skip cctest while building shared lib node for Windows
[ 'OS=="win" and node_shared=="true"', {
'type': 'none',
}],
[ 'node_shared=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', ],
},
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
],
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
],
}, # cctest
{
'target_name': 'embedtest',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
'deps/ada/ada.gyp:ada',
'deps/nbytes/nbytes.gyp:nbytes',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/sqlite',
'test/embedding',
],
'sources': [
'src/node_snapshot_stub.cc',
'test/embedding/embedtest.cc',
],
'conditions': [
['OS=="solaris"', {
'ldflags': [ '-I<(SHARED_INTERMEDIATE_DIR)' ]
}],
# Skip cctest while building shared lib node for Windows
[ 'OS=="win" and node_shared=="true"', {
'type': 'none',
}],
[ 'node_shared=="true"', {
'xcode_settings': {
'OTHER_LDFLAGS': [ '-Wl,-rpath,@loader_path', ],
},
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
],
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
],
}, # embedtest
{
'target_name': 'overlapped-checker',
'type': 'executable',
'conditions': [
['OS=="win"', {
'sources': [
'test/overlapped-checker/main_win.c'
],
}],
['OS!="win"', {
'sources': [
'test/overlapped-checker/main_unix.c'
],
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
]
}, # overlapped-checker
{
'target_name': 'node_js2c',
'type': 'executable',
'toolsets': ['host'],
'dependencies': [
'deps/simdutf/simdutf.gyp:simdutf#host',
],
'include_dirs': [
build: encode non-ASCII Latin1 characters as one byte in JS2C Previously we had two encodings for JS files: 1. If a file contains only ASCII characters, encode it as a one-byte string (interpreted as uint8_t array during loading). 2. If a file contains any characters with code point above 127, encode it as a two-byte string (interpreted as uint16_t array during loading). This was done because V8 only supports Latin-1 and UTF16 encoding as underlying representation for strings. To store the JS code as external strings to save encoding cost and memory overhead we need to follow the representations supported by V8. Notice that there is a gap in the Latin1 range (128-255) that we encoded as two-byte, which was an undocumented TODO for a long time. That was fine previously because then files that contained code points beyond the 0-127 range contained code points >255. Now we have undici which contains code points in the range 0-255 (minus a replaceable code point >255). So this patch adds handling for the 128-255 range to reduce the size overhead caused by encoding them as two-byte. This could reduce the size of the binary by ~500KB and helps future files with this kind of code points. Drive-by: replace `’` with `'` in undici.js to make it a Latin-1 only string. That could be removed if undici updates itself to replace this character in the comment. PR-URL: https://github.com/nodejs/node/pull/51605 Reviewed-By: Daniel Lemire <daniel@lemire.me> Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
2024-02-17 17:09:24 +00:00
'tools',
'src',
],
'sources': [
'tools/js2c.cc',
build: encode non-ASCII Latin1 characters as one byte in JS2C Previously we had two encodings for JS files: 1. If a file contains only ASCII characters, encode it as a one-byte string (interpreted as uint8_t array during loading). 2. If a file contains any characters with code point above 127, encode it as a two-byte string (interpreted as uint16_t array during loading). This was done because V8 only supports Latin-1 and UTF16 encoding as underlying representation for strings. To store the JS code as external strings to save encoding cost and memory overhead we need to follow the representations supported by V8. Notice that there is a gap in the Latin1 range (128-255) that we encoded as two-byte, which was an undocumented TODO for a long time. That was fine previously because then files that contained code points beyond the 0-127 range contained code points >255. Now we have undici which contains code points in the range 0-255 (minus a replaceable code point >255). So this patch adds handling for the 128-255 range to reduce the size overhead caused by encoding them as two-byte. This could reduce the size of the binary by ~500KB and helps future files with this kind of code points. Drive-by: replace `’` with `'` in undici.js to make it a Latin-1 only string. That could be removed if undici updates itself to replace this character in the comment. PR-URL: https://github.com/nodejs/node/pull/51605 Reviewed-By: Daniel Lemire <daniel@lemire.me> Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
2024-02-17 17:09:24 +00:00
'tools/executable_wrapper.h',
'src/embedded_data.h',
'src/embedded_data.cc',
],
'conditions': [
[ 'node_shared_libuv=="false"', {
'dependencies': [ 'deps/uv/uv.gyp:libuv#host' ],
}],
tools: speedup compilation of js2c output Incremental compilation of Node.js is slow. Currently on a powerful Linux machine, it takes about 9 seconds and 830 MB of memory to compile `gen/node_javascript.cc` with g++. This is the longest step when recompiling a small change to a Javascript file. `gen/node_javascript.cc` contains a lot of large binary literals of our Javascript source code. It is well-known that embedding large binary literals as C/C++ arrays is slow. One workaround is to include the data as string literals instead. This is particularly nice for the Javascript included via js2c, which look better as string literals anyway. Add a build flag `NODE_JS2C_USE_STRING_LITERALS` to js2c. When this flag is set, we emit string literals instead of array literals, i.e.: ```c++ // old: static const uint8_t X[] = { ... }; static const uint8_t *X = R"JS2C1b732aee(...)JS2C1b732aee"; // old: static const uint16_t Y[] = { ... }; static const uint16_t *Y = uR"JS2C1b732aee(...)JS2C1b732aee"; ``` This requires some modest refactoring in order to deal with the flag being on or off, but the new code itself is actually shorter. I only enabled the new flag on Linux/macOS, since those are systems that I have available for testing. On my Linux system with gcc, it speeds up compilation by 5.5s (9.0s -> 3.5s). On my Mac system with clang, it speeds up compilation by 2.2s (3.7s -> 1.5s). (I don't think this flag will work with MSVC, but it'd probably speed up clang on windows.) The long-term goal here is probably to allow this to occur incrementally per Javascript file & in parallel, to avoid recompiling all of `gen/node_javascript.cc`. Unfortunately the necessary gyp incantations seem impossible (or at least, far beyond me). Anyway, a 60% speedup is a nice enough win. Refs: https://github.com/nodejs/node/issues/47984 PR-URL: https://github.com/nodejs/node/pull/48160 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
2023-06-24 15:52:29 +00:00
[ 'OS in "linux mac"', {
'defines': ['NODE_JS2C_USE_STRING_LITERALS'],
}],
[ 'debug_node=="true"', {
'cflags!': [ '-O3' ],
'cflags': [ '-g', '-O0' ],
'defines': [ 'DEBUG' ],
'xcode_settings': {
'OTHER_CFLAGS': [
'-g', '-O0'
],
},
}],
]
},
{
'target_name': 'node_mksnapshot',
'type': 'executable',
'dependencies': [
'<(node_lib_target_name)',
'deps/histogram/histogram.gyp:histogram',
'deps/sqlite/sqlite.gyp:sqlite',
'deps/ada/ada.gyp:ada',
'deps/nbytes/nbytes.gyp:nbytes',
'deps/simdjson/simdjson.gyp:simdjson',
'deps/simdutf/simdutf.gyp:simdutf',
],
'includes': [
'node.gypi'
],
'include_dirs': [
'src',
'tools/msvs/genfiles',
'deps/v8/include',
'deps/cares/include',
'deps/uv/include',
'deps/sqlite',
],
'defines': [ 'NODE_WANT_INTERNALS=1' ],
'sources': [
'src/node_snapshot_stub.cc',
'tools/snapshot/node_mksnapshot.cc',
],
'msvs_settings': {
'VCLinkerTool': {
'EnableCOMDATFolding': '1', # /OPT:NOICF
},
},
'conditions': [
['node_write_snapshot_as_array_literals=="true"', {
'defines': [ 'NODE_MKSNAPSHOT_USE_ARRAY_LITERALS=1' ],
}],
[ 'node_use_openssl=="true"', {
'dependencies': [
'deps/ncrypto/ncrypto.gyp:ncrypto',
],
'defines': [
'HAVE_OPENSSL=1',
],
}],
[ 'node_use_node_code_cache=="true"', {
'defines': [
'NODE_USE_NODE_CODE_CACHE=1',
],
}],
['v8_enable_inspector==1', {
'defines': [
'HAVE_INSPECTOR=1',
],
}],
['OS=="win"', {
'libraries': [
'Dbghelp.lib',
'winmm.lib',
'Ws2_32.lib',
],
}],
# Avoid excessive LTO
['enable_lto=="true"', {
'ldflags': [ '-fno-lto' ],
}],
],
}, # node_mksnapshot
], # end targets
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
'conditions': [
['OS in "aix os400" and node_shared=="true"', {
'targets': [
{
'target_name': 'node_aix_shared',
'type': 'shared_library',
'product_name': '<(node_core_target_name)',
'ldflags': ['--shared'],
'product_extension': '<(shlib_suffix)',
'includes': [
'node.gypi'
],
'dependencies': ['<(node_lib_target_name)'],
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
'include_dirs': [
'src',
'deps/v8/include',
],
'sources': [
'<@(library_files)',
'<@(deps_files)',
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
'common.gypi',
],
'direct_dependent_settings': {
'ldflags': [ '-Wl,-brtl' ],
},
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
},
]
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
}], # end aix section
build: fix various shared library build issues Node.js unofficially supports a shared library variant where the main node executable is a thin wrapper around node.dll/libnode.so. The key benefit of this is to support embedding Node.js in other applications. Since Node.js 12 there have been a number of issues preventing the shared library build from working correctly, primarily on Windows: * A number of functions used executables such as `mksnapshot` are not exported from `libnode.dll` using a `NODE_EXTERN` attribute * A dependency on the `Winmm` system library is missing * Incorrect defines on executable targets leads to `node.exe` claiming to export a number of functions that are actually in `libnode.dll` * Because `node.exe` attempts to export symbols, `node.lib` gets generated causing native extensions to try to link against `node.exe` not `libnode.dll`. * Similarly, because `node.dll` was renamed to `libnode.dll`, native extensions don't know to look for `libnode.lib` rather than `node.lib`. * On macOS an RPATH is added to find `libnode.dylib` relative to `node` in the same folder. This works fine from the `out/Release` folder but not from an installed prefix, where `node` will be in `bin/` and `libnode.dylib` will be in `lib/`. * Similarly on Linux, no RPATH is added so LD_LIBRARY_PATH needs setting correctly for `bin/node` to find `lib/libnode.so`. For the `libnode.lib` vs `node.lib` issue there are two possible options: 1. Ensure `node.lib` from `node.exe` does not get generated, and instead copy `libnode.lib` to `node.lib`. This means addons compiled when referencing the correct `node.lib` file will correctly depend on `libnode.dll`. The down side is that native addons compiled with stock Node.js will still try to resolve symbols against node.exe rather than libnode.dll. 2. After building `libnode.dll`, dump the exports using `dumpbin`, and process this to generate a `node.def` file to be linked into `node.exe` with the `/DEF:node.def` flag. The export entries in `node.def` will all read ``` my_symbol=libnode.my_symbol ``` so that `node.exe` will redirect all exported symbols back to `libnode.dll`. This has the benefit that addons compiled with stock Node.js will load correctly into `node.exe` from a shared library build, but means that every embedding executable also needs to perform this same trick. I went with the first option as it is the cleaner of the two solutions in my opinion. Projects wishing to generate a shared library variant of Node.js can now, for example, ``` .\vcbuild dll package vs ``` to generate a full node installation including `libnode.dll`, `Release\node.lib`, and all the necessary headers. Native addons can then be built against the shared library build easily by specifying the correct `nodedir` option. For example ``` >npx node-gyp configure --nodedir C:\Users\User\node\Release\node-v18.0.0-win-x64 ... >npx node-gyp build ... >dumpbin /dependents build\Release\binding.node Microsoft (R) COFF/PE Dumper Version 14.29.30136.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file build\Release\binding.node File Type: DLL Image has the following dependencies: KERNEL32.dll libnode.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll ... ``` PR-URL: https://github.com/nodejs/node/pull/41850 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Richard Lau <rlau@redhat.com>
2022-02-04 10:12:57 +00:00
['OS=="win" and node_shared=="true"', {
'targets': [
{
'target_name': 'gen_node_def',
'type': 'executable',
'sources': [
'tools/gen_node_def.cc'
],
},
{
'target_name': 'generate_node_def',
'dependencies': [
'gen_node_def',
'<(node_lib_target_name)',
],
'type': 'none',
'actions': [
{
'action_name': 'generate_node_def_action',
'inputs': [
'<(PRODUCT_DIR)/<(node_lib_target_name).dll'
],
'outputs': [
'<(PRODUCT_DIR)/<(node_core_target_name).def',
],
'action': [
'<(PRODUCT_DIR)/gen_node_def.exe',
'<@(_inputs)',
'<@(_outputs)',
],
},
],
},
],
}], # end win section
build: Updates for AIX npm support - part 1 This PR is the first step enabling support for native modules for AIX. The main issue is that unlike linux where all symbols within the Node executable are available to the shared library for a native module (npm), on AIX the symbols must be explicitly exported. In addition, when the shared library is built it must be linked using a list of the available symbols. This patch covers the changes need to: 1) Export the symbols when building the node executable 2) Generate the file listing the symbols that can be used when building the shared library. For AIX, it breaks the build process into 2 steps. The first builds a static library and then generates a node.exp file which contains the symbols from that library. The second builds the node executable and uses the node.exp file to specify which symbols should be exported. In addition, it save the node.exp file so that it can later be used in the creation of the shared library when building a native module. The following additional steps will be required in dependent projects to fully enable AIX for native modules and are being worked separately: - Updates to node-gyp to use node.exp when creating the shared library for a native module - Fixes to gyp related to copying files as covered in https://codereview.chromium.org/1368133002/patch/1/10001 - Pulling in updated gyp versions to Node and node-gyp - Pulling latest libuv These changes were done to minimize the change to other platforms by working within the existing structure to add the 2 step process for AIX without changing the process for other platforms. PR-URL: https://github.com/nodejs/node/pull/3114 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
2015-09-29 14:22:00 +00:00
], # end conditions block
2011-08-04 00:01:30 +00:00
}