Hi --
I'm working on a C++ library that was compiling and linking just fine with
v8 until I upgraded to a new Mac (OS 10.12.5, clang++ version 802.0.42) and
moved up to the latest version of v8 (6.1.0). Now I'm getting lots of link
errors involving v8::ArrayBuffer::Allocator. I've reproduced the problem in
a minimal test case:
> clang++ -o v8linkfail -std=c++11 -stdlib=libc++ -Wall -Werror -O0
-fno-inline -g -Wall -Werror -O0 -fno-inline -g
-I/Users/scott/v8/v8/include v8linkfail.cpp -L/Users/scott/v8/v8/
out.gn/x64.debug/ -lv8 -lv8_libplatform -lv8_libbase -licuuc -licui18n
-lv8_for_testing
Undefined symbols for architecture x86_64:
"typeinfo for v8::ArrayBuffer::Allocator", referenced from:
typeinfo for DefaultV8ArrayBufferAllocator in v8linkfail-fbc69e.o
Here /Users/scott/v8 contains a v8 distribution checked out and built (
https://github.com/v8/v8/wiki/Building-with-GN)just yesterday, and
v8linkfail.cpp is a very simple test program:
/////////////////////// begin v8linkfail.cpp
#include <stdlib.h>
#include <v8.h>
class DefaultV8ArrayBufferAllocator: public v8::ArrayBuffer::Allocator {
public:
virtual void* Allocate(size_t length) {
void* data = AllocateUninitialized(length);
return data == NULL ? data : memset(data, 0, length);
}
virtual void* AllocateUninitialized(size_t length) {
return malloc(length);
}
virtual void Free(void* data, size_t) {
free(data);
}
};
int main(int argc, char** argv) {
std::unique_ptr<v8::ArrayBuffer::Allocator> alloc
(new DefaultV8ArrayBufferAllocator);
return 0;
}
////////////////////// end v8linkfail.cpp
This code compiles and links just fine with an older version of v8 (5.5.0)
(even on the same Mac on which v8 6.1.0 causes the link problems).
Looking at v8.h, I see that from 5.5.0 to 6.1.0, some new methods were
declared in ArrayBuffer::Allocator: Reserve(size_t), Free(void*, size_t,
AllocationMode), and SetProtection(void*, size_t, Protection). Normally a
link error like this would make me think "Ah hah! I bet somebody forgot to
define one of those new methods, and the vtable / type information is never
getting emitted because of that!", but as far as I can tell those new
methods are in fact all defined in (the 6.1.0 version of) api.cc, so I
don't see any problems there.
Looking at the guts of generated object files with nm -mo: when
v8linkfail.cpp is compiled to an object file using the old include files in
v8 5.5.0, the type info for ArrayBuffer::Allocator does in fact show up in
the generated object file (and everything links fine):
> nm -mo v8linkfail_v8_5.5.o | c++filt | grep type | grep Allocator
v8linkfail_v8_5.5.o: 0000000000000450 (__DATA,__data) weak external
typeinfo for DefaultV8ArrayBufferAllocator
v8linkfail_v8_5.5.o: 0000000000000438 (__DATA,__data) weak external
typeinfo for v8::ArrayBuffer::Allocator
v8linkfail_v8_5.5.o: 00000000000004a0 (__TEXT,__const) weak external
typeinfo name for DefaultV8ArrayBufferAllocator
v8linkfail_v8_5.5.o: 00000000000004c0 (__TEXT,__const) weak external
typeinfo name for v8::ArrayBuffer::Allocator
(Note: this is not exactly where I was expecting the typeinfo to show up --
I would have expected it in v8's api.o instead of my code's object file.
However, nm sees no mention of it in *either* the 5.5 or 6.1 version of
api.o, so I'm going to assume that this is somehow "normal" C++ behavior.)
On the other hand, when v8linkfail.cpp is compiled to an object file using
the include files in v8 6.1.0, the type info for ArrayBuffer::Allocator
becomes undefined, and that's when the link errors show up:
> nm -mo v8linkfail_v8_6.1.o | c++filt | grep type | grep Allocator
v8linkfail_v8_6.1.o: 0000000000000400 (__DATA,__data) weak external
typeinfo for DefaultV8ArrayBufferAllocator
v8linkfail_v8_6.1.o: (undefined) external typeinfo for
v8::ArrayBuffer::Allocator
v8linkfail_v8_6.1.o: 0000000000000420 (__TEXT,__const) weak external
typeinfo name for DefaultV8ArrayBufferAllocator
I'll admit I'm at a bit of a loss as to what's going on here, or how to
proceed. Is there a subtle bug somewhere either in v8's code (presumably
v8.h and/or api.cc) and/or in my definition of
DefaultV8ArrayBufferAllocator above? (By now I've stared at both my code
and v8's code to find this unlikely, but I could be missing something.) Or
is there a bug somewhere in the compiling/linking toolchain (yikes)? Or is
something funny going on because v8 was compiled with different tools or
flags than v8linkfail.cpp? If it might be the last of these (compiled with
different tools/flags), how might I go about determining exactly what tools
and flags all the bits of v8 were built with, and what flags should I be
suspicious of? (Building v8 with GN was not particularly transparent...is
there an easy way to pass in some sort of "-v"-like flag to ninja or
whatever that will dump all the commands used during the build while it's
building?)
Thanks,
-- Scott
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
