Build failure for armv7 architecture

[syuriks]

Version

16.14.2

Platform

Ubuntu 20.04.4 LTS

Subsystem

No response

What steps will reproduce the bug?

export 'CC_host=ccache gcc-9 -m32'
export 'CXX_host=ccache g++-9 -m32'
export 'CC=ccache /opt/pi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc -march=armv7-a'
export 'CXX=ccache /opt/pi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-g++ -march=armv7-a'
export 'CC_target=ccache /opt/pi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc -march=armv7-a'
export 'CXX_target=ccache /opt/pi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-g++ -march=armv7-a'
ccache /opt/pi-newer-crosstools/x64-gcc-8.3.0/arm-rpi-linux-gnueabihf/bin/arm-rpi-linux-gnueabihf-gcc -march=armv7-a --version
CONFIG_FLAGS=' --dest-cpu=arm'
python3 ./configure --verbose  --dest-cpu=arm
make

How often does it reproduce? Is there a required condition?

always

What is the expected behavior?

No response

What do you see instead?

touch /home/test/work/nodejs/node-v16.14.2/out/Release/obj.target/tools/v8_gypfiles/v8_compiler_for_mksnapshot.stamp
touch a3ff29809cd8dc72dd139addfb1007c6de16f2b9.intermediate
LD_LIBRARY_PATH=/home/test/work/nodejs/node-v16.14.2/out/Release/lib.host:/home/test/work/nodejs/node-v16.14.2/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../tools/v8_gypfiles; mkdir -p /home/test/work/nodejs/node-v16.14.2/out/Release/obj.target/v8_snapshot/geni; "/home/test/work/nodejs/node-v16.14.2/out/Release/mksnapshot" --turbo_instruction_scheduling "--target_os=linux" "--target_arch=arm" --startup_src "/home/test/work/nodejs/node-v16.14.2/out/Release/obj.target/v8_snapshot/geni/snapshot.cc" --embedded_variant Default --embedded_src "/home/test/work/nodejs/node-v16.14.2/out/Release/obj.target/v8_snapshot/geni/embedded.S" --no-native-code-counters
Unable to open file "/home/test/work/nodejs/node-v16.14.2/out/Release/obj.target/v8_snapshot/geni/embedded.S" for writing.

Additional information

Running strace I could see that embedded.S was created but was immediately closed before writing to it.

[belyak]

Hi! Thank you for the issue. I am experiencing the same problem and it would be nice to have it solved.

[eukarpov]

similar problem on Windows VS 2022 v17 has been fixed here
#46231

[lordrasmus]

i have the same issue when building for arm 32Bit on x86_64 using the ninja build system

the fix is only for windows

anyone an idea how to fix that on linux ?

Update:

the reason it fails on my system is this call in mksnapshot.cc and embedded-file-writer.h
FILE* fp = v8::base::OS::FOpen(filename, "wb");
when i replaced it with
FILE* fp = fopen(filename, "wb");
it works

i 'm not sure why that happens because FOpen is in gtest-port.h and just calls fopen() ??

and here is the full error message
Unable to open file "/mnt/m2_2/...../node-21.6.1/out/Release/obj/tools/v8_gypfiles/v8_snapshot.gen/snapshot.cc" for writing. Value too large for defined data type

maybe the 32 Bit g++ compiler is compiled without without large file support because the inode number for
snapshot.cc is 4406505298 ( 0x106a5ef52 ) which is more that 32 bit

stat output
Größe: 664820 Blöcke: 1304 EA Block: 4096 Normale Datei
Gerät: 259/1 Inode: 4406505298 Verknüpfungen: 1

but why does it work when i call fopen() instead of FOpen() ???

and here is the compiler cmd line :

g++ -m32 -MMD -MF obj.host/deps/v8/src/snapshot/mksnapshot.static-roots-gen.o.d -D_GLIBCXX_USE_CXX11_ABI=1 -DNODE_OPENSSL_CONF_NAME=nodejs_conf -DNODE_OPENSSL_HAS_QUIC -DICU_NO_USER_DATA_OVERRIDE -DV8_GYP_BUILD -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -D__STDC_FORMAT_MACROS -DOPENSSL_NO_PINSHARED -DOPENSSL_THREADS -DV8_TARGET_ARCH_ARM -DCAN_USE_ARMV7_INSTRUCTIONS -DCAN_USE_VFP3_INSTRUCTIONS -DCAN_USE_VFP32DREGS -DV8_HAVE_TARGET_OS -DV8_TARGET_OS_LINUX '-DV8_EMBEDDER_STRING="-node.19"' -DENABLE_DISASSEMBLER -DV8_PROMISE_INTERNAL_FIELD_COUNT=1 -DV8_ENABLE_PRIVATE_MAPPING_FORK_OPTIMIZATION -DOBJECT_PRINT -DV8_ATOMIC_OBJECT_FIELD_WRITES -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_USE_SIPHASH -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_USE_ZLIB -DV8_ENABLE_TURBOFAN -DV8_ENABLE_WEBASSEMBLY -DV8_ENABLE_JAVASCRIPT_PROMISE_HOOKS -DV8_ALLOCATION_FOLDING -DV8_ALLOCATION_SITE_TRACKING -DV8_ADVANCED_BIGINT_ALGORITHMS -DUSE_EABI_HARDFLOAT=1 -I../../deps/v8 -I../../deps/v8/include -Iobj.host/gen/generate-bytecode-output-root -Iobj.host/gen -pthread -Wno-unused-parameter -Wno-return-type -flax-vector-conversions -Wno-invalid-offsetof -fno-strict-aliasing -m32 -m32 -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -Og -ggdb3 -save-temps -fno-rtti -fno-exceptions -std=gnu++17 -c ../../deps/v8/src/snapshot/static-roots-gen.cc -o obj.host/deps/v8/src/snapshot/mksnapshot.static-roots-gen.o

[GustavPS]

i have the same issue when building for arm 32Bit on x86_64 using the ninja build system

the fix is only for windows

anyone an idea how to fix that on linux ?

Update:

the reason it fails on my system is this call in mksnapshot.cc and embedded-file-writer.h FILE* fp = v8::base::OS::FOpen(filename, "wb"); when i replaced it with FILE* fp = fopen(filename, "wb"); it works

i 'm not sure why that happens because FOpen is in gtest-port.h and just calls fopen() ??

and here is the full error message Unable to open file "/mnt/m2_2/...../node-21.6.1/out/Release/obj/tools/v8_gypfiles/v8_snapshot.gen/snapshot.cc" for writing. Value too large for defined data type

maybe the 32 Bit g++ compiler is compiled without without large file support because the inode number for snapshot.cc is 4406505298 ( 0x106a5ef52 ) which is more that 32 bit

stat output Größe: 664820 Blöcke: 1304 EA Block: 4096 Normale Datei Gerät: 259/1 Inode: 4406505298 Verknüpfungen: 1

but why does it work when i call fopen() instead of FOpen() ???

and here is the compiler cmd line :

g++ -m32 -MMD -MF obj.host/deps/v8/src/snapshot/mksnapshot.static-roots-gen.o.d -D_GLIBCXX_USE_CXX11_ABI=1 -DNODE_OPENSSL_CONF_NAME=nodejs_conf -DNODE_OPENSSL_HAS_QUIC -DICU_NO_USER_DATA_OVERRIDE -DV8_GYP_BUILD -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -D__STDC_FORMAT_MACROS -DOPENSSL_NO_PINSHARED -DOPENSSL_THREADS -DV8_TARGET_ARCH_ARM -DCAN_USE_ARMV7_INSTRUCTIONS -DCAN_USE_VFP3_INSTRUCTIONS -DCAN_USE_VFP32DREGS -DV8_HAVE_TARGET_OS -DV8_TARGET_OS_LINUX '-DV8_EMBEDDER_STRING="-node.19"' -DENABLE_DISASSEMBLER -DV8_PROMISE_INTERNAL_FIELD_COUNT=1 -DV8_ENABLE_PRIVATE_MAPPING_FORK_OPTIMIZATION -DOBJECT_PRINT -DV8_ATOMIC_OBJECT_FIELD_WRITES -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_USE_SIPHASH -DV8_SHARED_RO_HEAP -DV8_WIN64_UNWINDING_INFO -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH -DV8_USE_ZLIB -DV8_ENABLE_TURBOFAN -DV8_ENABLE_WEBASSEMBLY -DV8_ENABLE_JAVASCRIPT_PROMISE_HOOKS -DV8_ALLOCATION_FOLDING -DV8_ALLOCATION_SITE_TRACKING -DV8_ADVANCED_BIGINT_ALGORITHMS -DUSE_EABI_HARDFLOAT=1 -I../../deps/v8 -I../../deps/v8/include -Iobj.host/gen/generate-bytecode-output-root -Iobj.host/gen -pthread -Wno-unused-parameter -Wno-return-type -flax-vector-conversions -Wno-invalid-offsetof -fno-strict-aliasing -m32 -m32 -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -Og -ggdb3 -save-temps -fno-rtti -fno-exceptions -std=gnu++17 -c ../../deps/v8/src/snapshot/static-roots-gen.cc -o obj.host/deps/v8/src/snapshot/mksnapshot.static-roots-gen.o

Did you find any other solution other then changing to fopen?

[Darker]

I have the same problem targeting armv6. I am going to try if it can be fixed by changing the file open call. But this should probably be fixed, it was now reproduced on multiple platforms and compilers.

[OctopusET]

I'm having same problem on PPC64 (big-endian)

[Darker]

@OctopusET

This is what I did for both GetFileDescriptorOrDie:

  static FILE* GetFileDescriptorOrDie(const char* filename) {
    FILE* fp = fopen(filename, "wb");
    if (fp == nullptr) {
      i::PrintF("Unable to open file \"%s\" for writing, errno %d.\n", filename, errno);
      exit(1);
    }
    return fp;
  }

For bonus points, you could compile with the original v8::base::OS::FOpen but with the improved error message, so we can see what the error code is at least. I am not sure if I have the energy to do that, since the compilation takes several hours.

[OctopusET]

@Darker Thank you but I think I am getting same error but it may not related to that lines.
I will share more after I check more

[github-actions]

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[github-actions]

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.