Linking error for libplatform as of 24.11.1

Context:

I am the upstream author of the libv8 bindings for the R language.

For many years Fedora and Debian build libnode as a shared library, such that we can use the embedded libv8 engine in our language bindings. For this to work we need to link both to -lv8 -lv8_libplatform. Below is a minimal example.

Something seems to have broken, I think between 24.11.0 and 24.11.1. I can reproduce the problem both on Debian and Fedora with the nodejs 24.11.1 package.

Version

v24.11.1

Platform

Linux

What steps will reproduce the bug?

Compile the minimal hello world:

#include <libplatform/libplatform.h>
#include <v8.h>
using namespace v8;

int main(){
  std::unique_ptr<Platform> platform = platform::NewDefaultPlatform();
  V8::InitializePlatform(platform.get());
  V8::Initialize();
}

Compile with:

g++ -std=gnu++20 test.cpp -I/usr/include/v8 -lv8 -lv8_libplatform

This gives error:

test.cpp:(.text+0x39): undefined reference to `v8::platform::NewDefaultPlatform(int, v8::platform::IdleTaskSupport, v8::platform::InProcessStackDumping, std::unique_ptr<v8::TracingController, std::default_delete<v8::TracingController> >, v8::platform::PriorityMode)'
collect2: error: ld returned 1 exit status

It was working until 24.11.0

It's most likely to be because of #56290.

Do you think we need to mark the above function as visible? Or should we not shared libnode with -fvisibility=hidden ?

I think it's probably missing a definition for BUILDING_V8_PLATFORM_SHARED in the shared mode, as the public interface do have V8_PLATFORM_EXPORT. Though unfortunately there isn't any test about it, hence the breakage; I can see if I can put up a patch during the holidays, though it's unlikely to be released until after the holidays (it would be great though if you could send in a test to make sure that it won't be regressed again). Meanwhile, I think you might be able to fix it if the package adds -DBUILDING_V8_PLATFORM_SHARED to CXXFLAGS when building libnode through other means.

The most complete test would be to try and compile hello-world.cc or some variation thereof and link to libnode.so.

Or try to build the examples from the nodejs embedder docs

For a smaller test you can use the helloworld.cc given above.

Locally #61144 fixes it for me. I have a test that works locally in https://github.com/joyeecheung/node/tree/fix-shared-pl-test but I am fairly certain this requires quite a bit of tweaking to work in the various configurations in the CI. I personally don't have enough stake in this use case to get it work with the CI environment, so I'll only upstream the patch. Feel free to pick that test branch up for a different PR if you are interested in investing more time to get it pass in the CI and merged - note that until someone makes sure it's exercised in the CI, future breakages could go without being noticed again.

Thanks! Really appreciate the quick fix! I'll have a look over the break if I can conditionally add the test to the CI.

build: expose libplatform symbols in shared libnode

Actually it seems the team that I work with would like to see it tested, also I realized that in the CI, this path is only exercised on Linux. So I opened #61463

build: expose libplatform symbols in shared libnode

Navigation Menu

Repository navigation

Linking error for libplatform as of 24.11.1 #61102

Context:

Version

Platform

What steps will reproduce the bug?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Linking error for libplatform as of 24.11.1 #61102

Description

Context:

Version

Platform

What steps will reproduce the bug?

Activity

richardlau commented on Dec 17, 2025

jeroen commented on Dec 19, 2025

joyeecheung commented on Dec 20, 2025

jeroen commented on Dec 20, 2025

joyeecheung commented on Dec 21, 2025

jeroen commented on Dec 22, 2025

joyeecheung commented on Jan 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions