Building V8 then linking to it fails (OS X)

[Al Mo]

Hi all,

I'm trying to build v8 from source in order to test/submit a cl later on,

I followed this: https://v8.dev/docs/build

It builds fine and in the end I have an 'out/x64.release' directory, which in turn has the 'libv8_libbase.a' and 'libv8_libplatform.a' static libraries.

When trying to link against these libraries, I get undefined symbol errors, like:

  "v8::V8::Initialize(int)", referenced from:

      _main in main-df02fe.o

  "v8::V8::InitializePlatform(v8::Platform*)", referenced from:

      _main in main-df02fe.o

  "v8::V8::InitializeICUDefaultLocation(char const*, char const*)", referenced from:

      _main in main-df02fe.o

  "v8::V8::InitializeExternalStartupData(char const*)", referenced from:

      _main in main-df02fe.o

Checking the libraries with 'nm -gAC lib...' shows me that the symbols are not there at all,

I am not familiar with gn and the configuration options of v8, hence why I'm asking about it,

Any idea what could be going on?

Thanks.

[Ben Noordhuis]

There should be more than just those two archive files and link order
matters, you may need to shuffle them around when linking.

Can you post the output of `ls -l out/x64.release` and is there
perhaps also an out.gn directory in the top-level directory?

If there really aren't more *.a files, can you do a clean build and
post the output?

[Seth Brenith]

As well as those static libraries, the x64.release build creates a whole bunch of object files due to the "v8_source_set" declarations in BUILD.gn. Any gn build target defined as depending on the "v8" target will include not only those libs but also all of the objects from the source sets. The easiest way to get a linkable library is to add "v8_monolithic = true" to out/x64.release/args.gn and then build with "autoninja v8_monolith". This will create a single lib, libv8_monolith.a, which should have all of the relevant stuff included.

[Al Mo]

Thank you both for your replies,

After a clean build, here's the output of `ls -l ...`:

total 137768

-rw-r--r--    1 krrrunch  staff       214 Jun  1 12:29 args.gn

-rw-r--r--    1 krrrunch  staff     23922 Jun  1 20:17 build.ninja

-rw-r--r--    1 krrrunch  staff      3183 Jun  1 20:17 build.ninja.d

-rwxr-xr-x    1 krrrunch  staff    431628 Jun  1 20:21 bytecode_builtins_list_generator

-rwxr-xr-x    1 krrrunch  staff  26017224 Jun  1 20:54 d8

drwxr-xr-x    7 krrrunch  staff       224 Jun  1 20:54 gen

-rwxr-xr-x    1 krrrunch  staff   1318244 Jun  1 20:36 gen-regexp-special-case

-rw-r--r--    3 krrrunch  staff  10507280 Jun  1 10:31 icudtl.dat

-rwxr-xr-x    1 krrrunch  staff  29522824 Jun  1 20:54 mksnapshot

drwx------  105 krrrunch  staff      3360 Jun  1 20:54 obj

-rw-r--r--    1 krrrunch  staff     51188 Jun  1 20:54 snapshot_blob.bin

-rw-r--r--    1 krrrunch  staff     80153 Jun  1 20:17 toolchain.ninja

-rwxr-xr-x    1 krrrunch  staff   2557812 Jun  1 20:21 torque

-rw-r--r--    1 krrrunch  staff       523 Jun  1 20:20 v8_build_config.json

args.gn is:

is_component_build = false

is_debug = false

target_cpu = "x64"

use_goma = false

goma_dir = "None"

v8_enable_backtrace = true

v8_enable_disassembler = true

v8_enable_object_print = true

v8_enable_verify_heap = true

I have found no out.gn dir anywhere,

I lost the output of the last build but will do it again and post it as soon as I have it,

Also, will try the monolithic build and see if that helps,

Alex.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/4111796a-c053-4f16-9bf5-a1af0b99fc14%40googlegroups.com.

[Al Mo]

Update:

Full output of clean build:

# mkdir -p out/x64.release

# echo > out/x64.release/args.gn << EOF

is_component_build = false

is_debug = false

target_cpu = "x64"

use_goma = false

goma_dir = "None"

v8_enable_backtrace = true

v8_enable_disassembler = true

v8_enable_object_print = true

v8_enable_verify_heap = true

EOF

# gn gen out/x64.release

Done. Made 148 targets from 86 files in 751ms

# autoninja -C out/x64.release d8

ninja: Entering directory `out/x64.release'

[1450/1450] LINK ./d8

Done! - V8 compilation finished successfully.

[Al Mo]

Update,

Just finished a monolithic build and got a 'libv8_monolith.a', when I link against it everything works, that will do for me,

If you wish me to continue doing some research on to why it wasn't working the other way, let me know what to do,

Thanks all,

Alex.

[Al Mo]

The mystery deepens,

I can compile/link against the monolith library,

I am trying to run the hello-world.cc sample, only change I made is I added `#define V8_COMPRESS_POINTERS` (but also tried without it and using a v8 compiled w/o pointer compression),

The program gets stuck when I call `v8::V8::Initialize();`,

I plug Instruments into and I see this:

I tried compiling a debug version to get more info but it fails very bad if I try the monolith thing, w/o monolith I run into the same issue of missing symbols,

Any idea on what could be going on? Or how to debug it further? Willing to put time into this :)

Alex.

[Al Mo]

Hello again,

Today I decided to spin up a virtual machine and give it a try on a linux environment (instead of OS X),

On a fresh install of Ubuntu 20.04 + build tools (make, clang, etc...), I fetch the latest v8 with depot_tools/git and try to compile v8,

I have found the exact same issues as my OS X system:

* Same symbols missing on libv8_libbase and libv8_libplatform

* When I do a monolithic release and link against libv8_monolith, the symbols are there and I can compile, but when I run the program it gets stuck (forever?) on `v8::V8::Initialize()`.

Any comments?

Anybody has compiled v8 from source (and from scratch) recently?

Alex.

[Seth Brenith]

I'm surprised by the fact that it gets stuck in Initialize. I haven't heard of similar bugs before, but perhaps others could provide useful advice.

However, going back to your original message, I see that your goal is "to test/submit a cl later on". You already built d8, which is a command-line program capable of running JavaScript files. Is it capable of providing the testing you need? Or if your change requires lower-level testing, could you perhaps add the relevant tests to unittests or cctest? Creating a new custom program that uses V8 seems like more work than necessary, unless I'm misunderstanding your goal.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-...@googlegroups.com.

[Al Mo]

Thanks Seth,

I was able to finally get it running through a combination of args that disabled compressed pointer, disabled the custom libc, etc...

Same behavior on OS X and Ubuntu, so it may be something worth to check out later.

If I find the cause I'll let you know and try to fix it :)

Best,

Alex.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/d46f95b9-9dff-4e75-8759-5b167af7eecc%40googlegroups.com.