Skip to content

Build failure for armv7 architecture #45431

Closed as not planned
Closed as not planned
Build failure for armv7 architecture#45431
Labels
staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Description

@syuriks
syuriks
opened on Nov 11, 2022

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.

Activity

  1. belyak commented on Nov 13, 2022

    @belyak
    belyak
    on Nov 13, 2022

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

  2. eukarpov commented on Jan 17, 2023

    @eukarpov
    eukarpov
    on Jan 17, 2023

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

  3. lordrasmus commented on Feb 3, 2024

    @lordrasmus
    lordrasmus
    on Feb 3, 2024

    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

  4. GustavPS commented on Sep 17, 2024

    @GustavPS
    GustavPS
    on Sep 17, 2024

    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?

  5. Darker commented on Jan 4, 2025

    @Darker
    Darker
    on Jan 4, 2025

    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.

  6. OctopusET commented on Jan 5, 2025

    @OctopusET
    OctopusET
    on Jan 5, 2025

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

  7. Darker commented on Jan 5, 2025

    @Darker
    Darker
    on Jan 5, 2025

    @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.

  8. OctopusET commented on Jan 6, 2025

    @OctopusET
    OctopusET
    on Jan 6, 2025

    @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

  9. github-actions commented on Jun 23, 2026

    @github-actions
    github-actionsbot
    on Jun 23, 2026 – with GitHub Actions
    Contributor

    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.

  10. github-actions
    added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 23, 2026

  11. github-actions commented on Jul 24, 2026

    @github-actions
    github-actionsbot
    on Jul 24, 2026 – with GitHub Actions
    Contributor

    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.

  12. github-actions
    closed this as not plannedon Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions