Skip to content

Conversation

@jeroen
Copy link
Contributor

@jeroen jeroen commented Jul 29, 2019

This is needed for external applications to link to shared libnode. Fixes #27431

  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

@refack does this seem OK?

@nodejs-github-bot nodejs-github-bot added the build Issues and PRs related to build files or the CI. label Jul 29, 2019
This is needed for external applications that link to shared libnode.
Fixes #27431
@jeroen jeroen marked this pull request as ready for review July 29, 2019 21:07
@Trott
Copy link
Member

Trott commented Aug 1, 2019

@nodejs/node-gyp

@nodejs-github-bot
Copy link
Collaborator

CI: https://ci.nodejs.org/job/node-test-pull-request/24804/

@Trott Trott requested a review from refack August 1, 2019 05:48
Copy link
Member

@bnoordhuis bnoordhuis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM.

Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I'm not a gyp expert, but CI is green, got another approval from a domain expert, and this would be easy to revert if it came to it. So 👍 .

@Trott
Copy link
Member

Trott commented Aug 1, 2019

Landed in ed138ba

@Trott Trott closed this Aug 1, 2019
Trott pushed a commit to Trott/io.js that referenced this pull request Aug 1, 2019
This is needed for external applications that link to shared libnode.
Fixes nodejs#27431

PR-URL: nodejs#28897
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
targos pushed a commit that referenced this pull request Aug 2, 2019
This is needed for external applications that link to shared libnode.
Fixes #27431

PR-URL: #28897
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
joyeecheung added a commit to joyeecheung/node that referenced this pull request Nov 26, 2019
To build mkcodecache and mksnapshot (they are executables),
we currently build libnode with unresolved symbols, then build
the two exectuables with src/node_snapshot_stub.cc and
src/node_code_cache_stub.cc. Each of them write a C++ file to
disk when being run. We then use the generated C++ files & libnode
(with unresolved symbols) to build the final Node executable.

However, if libnode itself is the final product, then we should
not build it with unresolved symbols.
nodejs#28897 added the two stubs
for the libnode target when the --shared configure option is used,
but it did not get rid of the actions to build and run mksnapshot
and mkcodecache for --shared, so I think to get it working we also
need a patch to make sure --shared imply --without-node-code-cache
and --without-node-snapshot, until we actually fix the TODO so that
mksnapshot and mkcodecache do not use the libnode that way.
joyeecheung added a commit that referenced this pull request Dec 3, 2019
To build mkcodecache and mksnapshot (they are executables),
we currently build libnode with unresolved symbols, then build
the two exectuables with src/node_snapshot_stub.cc and
src/node_code_cache_stub.cc. Each of them write a C++ file to
disk when being run. We then use the generated C++ files & libnode
(with unresolved symbols) to build the final Node executable.

However, if libnode itself is the final product, then we should
not build it with unresolved symbols.
#28897 added the two stubs
for the libnode target when the --shared configure option is used,
but it did not get rid of the actions to build and run mksnapshot
and mkcodecache for --shared, so to get it working we also
need a patch to make sure --shared imply --without-node-code-cache
and --without-node-snapshot, until we actually fix the TODO so that
mksnapshot and mkcodecache do not use the libnode that way.

PR-URL: #30647
Refs: #28845
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: David Carlier <[email protected]>
Reviewed-By: James M Snell <[email protected]>
BridgeAR pushed a commit that referenced this pull request Dec 3, 2019
To build mkcodecache and mksnapshot (they are executables),
we currently build libnode with unresolved symbols, then build
the two exectuables with src/node_snapshot_stub.cc and
src/node_code_cache_stub.cc. Each of them write a C++ file to
disk when being run. We then use the generated C++ files & libnode
(with unresolved symbols) to build the final Node executable.

However, if libnode itself is the final product, then we should
not build it with unresolved symbols.
#28897 added the two stubs
for the libnode target when the --shared configure option is used,
but it did not get rid of the actions to build and run mksnapshot
and mkcodecache for --shared, so to get it working we also
need a patch to make sure --shared imply --without-node-code-cache
and --without-node-snapshot, until we actually fix the TODO so that
mksnapshot and mkcodecache do not use the libnode that way.

PR-URL: #30647
Refs: #28845
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: David Carlier <[email protected]>
Reviewed-By: James M Snell <[email protected]>
targos pushed a commit that referenced this pull request Jan 14, 2020
To build mkcodecache and mksnapshot (they are executables),
we currently build libnode with unresolved symbols, then build
the two exectuables with src/node_snapshot_stub.cc and
src/node_code_cache_stub.cc. Each of them write a C++ file to
disk when being run. We then use the generated C++ files & libnode
(with unresolved symbols) to build the final Node executable.

However, if libnode itself is the final product, then we should
not build it with unresolved symbols.
#28897 added the two stubs
for the libnode target when the --shared configure option is used,
but it did not get rid of the actions to build and run mksnapshot
and mkcodecache for --shared, so to get it working we also
need a patch to make sure --shared imply --without-node-code-cache
and --without-node-snapshot, until we actually fix the TODO so that
mksnapshot and mkcodecache do not use the libnode that way.

PR-URL: #30647
Refs: #28845
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: David Carlier <[email protected]>
Reviewed-By: James M Snell <[email protected]>
BethGriggs pushed a commit that referenced this pull request Feb 6, 2020
To build mkcodecache and mksnapshot (they are executables),
we currently build libnode with unresolved symbols, then build
the two exectuables with src/node_snapshot_stub.cc and
src/node_code_cache_stub.cc. Each of them write a C++ file to
disk when being run. We then use the generated C++ files & libnode
(with unresolved symbols) to build the final Node executable.

However, if libnode itself is the final product, then we should
not build it with unresolved symbols.
#28897 added the two stubs
for the libnode target when the --shared configure option is used,
but it did not get rid of the actions to build and run mksnapshot
and mkcodecache for --shared, so to get it working we also
need a patch to make sure --shared imply --without-node-code-cache
and --without-node-snapshot, until we actually fix the TODO so that
mksnapshot and mkcodecache do not use the libnode that way.

PR-URL: #30647
Refs: #28845
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: David Carlier <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Issues and PRs related to build files or the CI.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Link issue with static library of nodejs

4 participants