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