Hello World sample build failure

34 views
Skip to first unread message

Justin Ferguson

unread,
Oct 31, 2024, 10:02:38 PM10/31/24
to v8-dev
Hello,

I'm trying to compile the sample hello world program as exhibited in the embedding v8 howto. The compile of v8 goes fine, however when I try to build the sample application I get the following:

$ g++ -I. -Iinclude samples/hello-world.cc -o hello_world -fno-rtti -lv8_monolith -lv8_libbase -lv8_libplatform -ldl -Lout.gn/x64.release/obj/ -pthread -std=c++20 -DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
/usr/bin/ld: out.gn/x64.release/obj//libv8_monolith.a(default-platform.o): unknown type [0x40000014] section `.crel.text'
/usr/bin/ld: out.gn/x64.release/obj//libv8_monolith.a(default-thread-isolated-allocator.o): unknown type [0x40000014] section `.crel.text'
/usr/bin/ld: out.gn/x64.release/obj//libv8_monolith.a(default-worker-threads-task-runner.o): unknown type [0x40000014] section `.crel.text'
[ several pages of this]
/usr/bin/ld: skipping incompatible out.gn/x64.release/obj//libv8_libplatform.a when searching for -lv8_libplatform
/usr/bin/ld: cannot find -lv8_libplatform: No such file or directory
collect2: error: ld returned 1 exit status

Googling around I see that usually the 'skipping incompatible...' error relates to mismatching 32-bit and 64-bit builds which is not the case here (I checked the object files with file).

v8 source was pulled down and is current as of today and:

$ g++ --version
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat /etc/debian_version
bookworm/sid

Any suggestions?

Best Regards,

Justin N. Ferguson

Ben Noordhuis

unread,
Nov 1, 2024, 4:58:34 AM11/1/24
to v8-...@googlegroups.com
Try clang++; I don't think g++/binutils supports CREL yet. You can
also try to build V8 with g++ (is_clang=false)

Justin Ferguson

unread,
Nov 1, 2024, 12:05:27 PM11/1/24
to v8-...@googlegroups.com
Hi all,

> Try clang++; I don't think g++/binutils supports CREL yet. You can
> also try to build V8 with g++ (is_clang=false)

I've tried with both clang and g++ with the same result. I actually
decided to blow away the Linux install I had and try again with a
fresh install that was the latest and the CREL warnings go away but
the problem with libv8_libplatform remains:

$ g++ -I. -Iinclude samples/hello-world.cc -o hello_world -fno-rtti
-lv8_monolith -lv8_libbase -lv8_libplatform -ldl
-Lout.gn/x64.release.sample/obj/ -pthread -std=c++20
-DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
/usr/bin/ld: skipping incompatible
out.gn/x64.release.sample/obj//libv8_libplatform.a when searching for
-lv8_libplatform
/usr/bin/ld: cannot find -lv8_libplatform: No such file or directory
collect2: error: ld returned 1 exit status
$ file out.gn/x64.release.sample/obj/libv8_libplatform.a
out.gn/x64.release.sample/obj/libv8_libplatform.a: thin archive with
292 symbol entries

Ben Noordhuis

unread,
Nov 1, 2024, 2:25:23 PM11/1/24
to v8-...@googlegroups.com
That error (non-fatal warning actually) suggests it was built for a
different architecture. Does it work when you pass -m32 or -m64 to
g++?

Justin Ferguson

unread,
Nov 1, 2024, 3:58:13 PM11/1/24
to v8-...@googlegroups.com
> That error (non-fatal warning actually) suggests it was built for a
> different architecture. Does it work when you pass -m32 or -m64 to
> g++?

Yeah I tried that, (on the original linux box) -m32 gave errors
relating to like crt.o or whatever and so forth. -m64 yields the error
listed in the prior email. Here's both on the new Linux installation:

$ g++ -m32 -I. -Iinclude samples/hello-world.cc -o hello_world
-fno-rtti -lv8_monolith -lv8_libbase -lv8_libplatform -ldl
-Lout.gn/x64.release.sample/obj/ -pthread -std=c++20
-DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
In file included from samples/hello-world.cc:5:
/usr/include/stdio.h:28:10: fatal error: bits/libc-header-start.h: No
such file or directory
28 | #include <bits/libc-header-start.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
$ g++ -m64 -I. -Iinclude samples/hello-world.cc -o hello_world
-fno-rtti -lv8_monolith -lv8_libbase -lv8_libplatform -ldl
-Lout.gn/x64.release.sample/obj/ -pthread -std=c++20
-DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
/usr/bin/ld: skipping incompatible
out.gn/x64.release.sample/obj//libv8_libplatform.a when searching for
-lv8_libplatform
/usr/bin/ld: cannot find -lv8_libplatform: No such file or directory
collect2: error: ld returned 1 exit status

Interestingly, if I omit the link directive on the command line to
link in libv8_libplatform I get the following:
$ g++ -m64 -I. -Iinclude samples/hello-world.cc -o hello_world
-fno-rtti -lv8_monolith -lv8_libbase -ldl
-Lout.gn/x64.release.sample/obj/ -pthread -std=c++20
-DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-platform.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-thread-isolated-allocator.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-worker-threads-task-runner.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(delayed-task-queue.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(tracing-controller.o)'
is incompatible with i386:x86-64 output
[ repeated across 3 or 4 screens ]

When I run file over the object (.o) files used to build
libv8_monolith.a and libv8_libplatform.a I get that they're all
64-bit, so while this issue is usually relating to x86/x64 it isn't in
this case:
$ mkdir junk
$ cd junk
$ ar x ../libv8_monolith.a
$ file *.o
abort-mode.o: ELF 64-bit LSB
relocatable, x86-64, version 1 (SYSV), not stripped
abstract-code.o: ELF 64-bit LSB
relocatable, x86-64, version 1 (SYSV), not stripped
access-builder.o: ELF 64-bit LSB
relocatable, x86-64, version 1 (SYSV), not stripped
access-info.o: ELF 64-bit LSB
relocatable, x86-64, version 1 (SYSV), not stripped
accessors.o: ELF 64-bit LSB
relocatable, x86-64, version 1 (SYSV), not stripped
[...]
$ cd v8_libplatform/
$ file *.o
default-foreground-task-runner.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
default-job.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
default-platform.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
default-thread-isolated-allocator.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
default-worker-threads-task-runner.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
delayed-task-queue.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
task-queue.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
trace-buffer.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
trace-config.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
trace-object.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
trace-writer.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
tracing-controller.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped
worker-thread.o: ELF 64-bit LSB relocatable,
x86-64, version 1 (SYSV), not stripped


I should also note the test suite completes successfully, so it builds
and tests properly.

Justin

Ben Noordhuis

unread,
Nov 2, 2024, 5:39:28 AM11/2/24
to v8-...@googlegroups.com
Long shot but, since you're linking to libv8_monolith.a anyway, why
not drop libv8_libbase from the arguments?

Justin Ferguson

unread,
Nov 2, 2024, 2:42:59 PM11/2/24
to v8-...@googlegroups.com
Hi,


> Long shot but, since you're linking to libv8_monolith.a anyway, why
> not drop libv8_libbase from the arguments?

I get the same thing as with it:

$ g++ -m64 -I. -Iinclude samples/hello-world.cc -o hello_world
-fno-rtti -lv8_monolith -ldl -Lout.gn/x64.release.sample/obj/ -pthread
-std=c++20 -DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-platform.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-thread-isolated-allocator.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-worker-threads-task-runner.o)'
is incompatible with i386:x86-64 output
[...]

I should note that whenever I omit either of the library directives
and I get these screens full of errors from ld that the build process
hangs. I'm going to leave it and see what its final conclusion is, but
I think the build is broken-- this is a fresh linux install with all
of the instructions followed and the only thing done on the box was
build v8.

Justin

Justin Ferguson

unread,
Nov 2, 2024, 3:34:32 PM11/2/24
to v8-...@googlegroups.com
Hi,

Following up with what I said about the build hanging when I omit the
libv8_libplatform.a and libv8_libbase.a. It takes a long time and
hangs but eventually turns up:

$ g++ -m64 -I. -Iinclude samples/hello-world.cc -o hello_world
-fno-rtti -lv8_monolith -ldl -Lout.gn/x64.release.sample/obj/ -pthread
-std=c++20 -DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-platform.o)'
is incompatible with i386:x86-64 output
/usr/bin/ld: unknown architecture of input file
`out.gn/x64.release.sample/obj//libv8_monolith.a(default-thread-isolated-allocator.o)'
is incompatible with i386:x86-64 output
[...]
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(default-platform.o)(.eh_frame);
no .eh_frame_hdr table will be created
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(default-thread-isolated-allocator.o)(.eh_frame);
no .eh_frame_hdr table will be created
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(default-worker-threads-task-runner.o)(.eh_frame);
no .eh_frame_hdr table will be created
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(delayed-task-queue.o)(.eh_frame);
no .eh_frame_hdr table will be created
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(tracing-controller.o)(.eh_frame);
no .eh_frame_hdr table will be created
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(api.o)(.eh_frame); no
.eh_frame_hdr table will be created
[...]
/usr/bin/ld: error in
out.gn/x64.release.sample/obj//libv8_monolith.a(memory-lowering.o)(.eh_frame);
no .eh_frame_hdr table will be created
collect2: error: ld returned 1 exit status
$

I'm probably going to file a bug and escalate there, its a brand new
fresh linux system and this is consistently happening, seems like it
would affect everyone on the same platform.

Justin Ferguson

unread,
Nov 3, 2024, 3:12:24 PM11/3/24
to v8-...@googlegroups.com
Hello all,

Does anyone happen to know the URL for the v8 bug reporting site? The
link I have is for chromium and when you go to file it only allows you
to select chromium versions as the affected software, so it seems
wrong and figured I'd check here before potentially filing in the
wrong place.

As an aside, I also tried turning the thin archives of
libv8_libplatform.a and libv8_libbase.a into regular archive files
with no changes in outcome.

Justin

seth.b...@microsoft.com

unread,
Nov 4, 2024, 11:33:29 AM11/4/24
to v8-dev
Hi Justin,

V8 bugs are tracked in the same site as Chromium bugs these days. When creating an issue, start by selecting the component "Chromium > Blink > JavaScript". The reporting template changes depending on the component you select.

Best,
Seth

Justin Ferguson

unread,
Nov 4, 2024, 2:57:28 PM11/4/24
to v8-...@googlegroups.com
Hello all,

Thank you for the information about bug reporting. For posterity's
sake, because when I searched for the literals of my problem I found
zero relevant results: I filed a bug that can be found here:
https://issues.chromium.org/issues/377222400

Best Regards,

Justin N. Ferguson

> --
> --
> 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 visit https://groups.google.com/d/msgid/v8-dev/7d36b767-533d-437e-933d-d4b8f92785dan%40googlegroups.com.

Jakob Kummerow

unread,
Nov 5, 2024, 8:27:46 AM11/5/24
to v8-...@googlegroups.com
I can repro.

Looks like -fuse-ld=lld makes it work. Plain ld is probably missing some support. I'll update the docs.

Justin Ferguson

unread,
Nov 5, 2024, 1:43:25 PM11/5/24
to v8-...@googlegroups.com
Hello all,

> Looks like -fuse-ld=lld makes it work. Plain ld is probably missing some support. I'll update the docs.

I can confirm that this works for me and resolved the problem. It
required me to "apt install lld" because the alternative loader was
not included in the build/install-build-deps.sh. Prior to that I got
the error:

$ g++ -I. -Iinclude samples/hello-world.cc -o hello_world -fno-rtti
-lv8_monolith -fuse-ld=lld -ldl -Lout.gn/x64.release.sample/obj/
-pthread -std=c++20 -DV8_COMPRESS_POINTERS -DV8_ENABLE_SANDBOX
collect2: fatal error: cannot find ‘ld’
compilation terminated.

Thanks for the pointer.
Reply all
Reply to author
Forward
0 new messages