v8-3.2.8.2: cannot compile shell when building v8 as a shared library

[Paweł Hajdan, Jr.]

I'm using v8-3.2.8.2, and compiling it as a shared library gives the following result:

i686-pc-linux-gnu-g++ -o shell -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -m32 obj/sample/shell/release/shell.o -L. -lv8-3.2.8.2 -lpthread

obj/sample/shell/release/shell.o: In function `RunMain(int, char**)':

shell.cc:(.text+0xf7c): undefined reference to `v8::internal::Thread::Join()'

shell.cc:(.text+0x1080): undefined reference to `v8::internal::Thread::Thread(v8::internal::Isolate*, v8::internal::Thread::Options const&)'

shell.cc:(.text+0x1097): undefined reference to `v8::internal::Thread::Start()'

shell.cc:(.text+0x1113): undefined reference to `v8::internal::OS::CreateSemaphore(int)'

shell.cc:(.text+0x1121): undefined reference to `v8::internal::OS::CreateSemaphore(int)'

obj/sample/shell/release/shell.o: In function `SourceGroup::IsolateThread::~IsolateThread()':

shell.cc:(.text._ZN11SourceGroup13IsolateThreadD1Ev[SourceGroup::IsolateThread::~IsolateThread()]+0x14): undefined reference to `v8::internal::Thread::~Thread()'

obj/sample/shell/release/shell.o: In function `SourceGroup::IsolateThread::~IsolateThread()':

shell.cc:(.text._ZN11SourceGroup13IsolateThreadD0Ev[SourceGroup::IsolateThread::~IsolateThread()]+0x14): undefined reference to `v8::internal::Thread::~Thread()'

collect2: ld returned 1 exit status

scons: *** [shell] Error 1

scons: building terminated because of errors.

I'm also attaching a full build log.

Could you please fix this build issue? Also, are you testing the shared library build in the continuous integration, or at least before doing a tagged release?

[Søren Gjesse]

I am afraid that from the isolates merge (r7271) building the sample shell using shared libraries does no longer work. This is due to the sample shell not using APIs internal to v8 which is not exported through include/v8.h. For testing isolates we needed thread support for running tests, and currently the developer shell d8 is not suited for running tests threads where added to the sample shell using internal V8 thread support. We have issue 1272 open on this.

It is still possible to build the process sample using V8 in a shared library.

$ ldd process 

linux-gate.so.1 =>  (0xf7777000)

libv8.so => ./libv8.so (0xf7354000)

libpthread.so.0 => /lib32/libpthread.so.0 (0xf7319000)

libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7222000)

libm.so.6 => /lib32/libm.so.6 (0xf71fc000)

libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf71dd000)

libc.so.6 => /lib32/libc.so.6 (0xf7083000)

/lib/ld-linux.so.2 (0xf7778000)

For chromium there is a builder building using shared libraries on the main waterfall, http://build.chromium.org/p/chromium/builders/Win%20Builder%20%28dbg%29%28shared%29, and that will turn red if the Windows build using shared libraries fails.

Regards,

Søren

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users

[Paweł Hajdan, Jr.]

2011/4/8 Søren Gjesse <sgj...@chromium.org>

I am afraid that from the isolates merge (r7271) building the sample shell using shared libraries does no longer work. This is due to the sample shell not using APIs internal to v8 which is not exported through include/v8.h. For testing isolates we needed thread support for running tests, and currently the developer shell d8 is not suited for running tests threads where added to the sample shell using internal V8 thread support. We have issue 1272 open on this.

It is still possible to build the process sample using V8 in a shared library.

Thank you. Can the tests be run with the process sample instead of the shell sample?

I just need the shell to run tests. This is for a Linux distribution, so V8 is built as a shared library.

[Søren Gjesse]

On Linux (and other platforms using gcc) you could use the option visibility=default to expose all of libv8.so - that will make the shell build with the shared library, but increase the size of libv8.so by about 10% and provide other clients of libv8.so to use internal APIs.

Otherwise I am afraid that you are out of luck. There is no way of running the tests with a shared library, and there probably will not be in the foreseeable future. If we decide to turn the shell back to a simple sample without the additional test supporting options and threading it will be possible to build it with shared library support, but it will not be able to run tests. d8 will then be updated to run tests, but as d8 is heavily dependent on v8::internal:: stuff it will not be buildable with a shared library.

Regards,

Søren

[Paweł Hajdan, Jr.]

On Fri, Apr 8, 2011 at 12:42, Søren Gjesse <sgj...@chromium.org> wrote:

On Linux (and other platforms using gcc) you could use the option visibility=default to expose all of libv8.so - that will make the shell build with the shared library, but increase the size of libv8.so by about 10% and provide other clients of libv8.so to use internal APIs.

Right, this indeed made it compile.

 

Otherwise I am afraid that you are out of luck. There is no way of running the tests with a shared library, and there probably will not be in the foreseeable future. If we decide to turn the shell back to a simple sample without the additional test supporting options and threading it will be possible to build it with shared library support, but it will not be able to run tests. d8 will then be updated to run tests, but as d8 is heavily dependent on v8::internal:: stuff it will not be buildable with a shared library.

Could you consider another testing strategy then? V8 is not just used by Google Chrome the web browser. It is used by MongoDB, Node.js and probably other projects too. Linux distributions want to ship it as a shared library, and they want to run tests to make sure they pass (and a JS engine is non-trivial code, so it's really important; recently I've seen V8 test failures on arm-hardfloat, and they were detecting real issues).

[Søren Gjesse]

We will discuss how to address the testing using shared library, however as I see it the testing shell would have to have its own (cross platform) implementation of threading - maybe we could add something to v8::Testing, but we don't want people starting to use it in general.

Regarding arm-hardfloat there is currently no V8 support for that, and it will have unexpected behaviour if used (we should actually add a #error for that). On what platforms are arm-hardfloat used?

Regards,

Søren

[Paweł Hajdan, Jr.]

On Sun, Apr 10, 2011 at 12:53, Søren Gjesse <sgj...@chromium.org> wrote:

Regarding arm-hardfloat there is currently no V8 support for that, and it will have unexpected behaviour if used (we should actually add a #error for that). On what platforms are arm-hardfloat used?

See v8 report: http://code.google.com/p/v8/issues/detail?id=1301 and a downstream report (Gentoo Linux): http://bugs.gentoo.org/show_bug.cgi?id=359911