[Pkg-chromium-maint] Bug#627033: FTBFS: v8/src/arm/macro-assembler-arm.cc:61:3: error: #error "For thumb inter-working we require an architecture which supports blx"

Timo Juhani Lindfors timo.lindfors at iki.fi
Tue May 17 06:32:27 UTC 2011


Package: chromium-browser
Version: 11.0.696.65~r84435-1
Severity: serious

(I'm documenting extra stuff here. The build takes so long that I don't
want to forget any details...)

Yesterday I tried to build chromium (with ld.bfd) and got

  g++ -pthread -Wl,-z,noexecstack -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections  -o out/Release/protoc -Wl,--start-group out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/code_generator.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/command_line_interface.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/plugin.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/plugin.pb.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/subprocess.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/zip_writer.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_enum.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_enum_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_extension.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_file.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_generator.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_helpers.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_primitive_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_service.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_string_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_enum.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_enum_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_extension.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_file.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_generator.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_helpers.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_message.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_message_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_primitive_field.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/java/java_service.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/python/python_generator.o out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/main.o out/Release/obj.host/third_party/protobuf/libprotobuf_full_do_not_use.a out/Release/obj.host/third_party/protobuf/libprotobuf_lite.a -Wl,--end-group
collect2: ld terminated with signal 11 [Segmentation fault]

This matches exactly what ubuntu is seeing too:

"  CXX(host)
   out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/main.o
   LINK(host) out/Release/protoc
 collect2: ld terminated with signal 11 [Segmentation fault]"

-- https://launchpadlibrarian.net/71622655/buildlog_ubuntu-oneiric-armel.chromium-browser_11.0.696.68~r84545-0ubuntu1_FAILEDTOBUILD.txt.gz

Oddly enough if I run the exact same g++ command manually it succeeds! I
began to debug this:

1) I replaced /usr/bin/ld with a symlink to a script that does

#!/bin/sh

while true; do
    /usr/bin/ld.bfd "$@"
    ret=$?
    if [ "$ret" = 0 ]; then
        break
    fi
    echo "linker failed:" 1>&2
    echo "ld.bfd $@" 1>&2
    echo "return value is $ret" 1>&2

    while true; do
        echo "run (s)hell / (r)etry build / (q)uit? " 1>&2
        read reply
        case "$reply" in
            s)
                echo "dropping you to shell" 1>&2
                bash
                echo "shell exiting" 1>&2
                ;;
            r)
                echo "retrying build" 1>&2
                break
                ;;
            q)
                echo "giving up" 1>&2
                exit $ret
                ;;
            *)
                echo "invalid reply" 1>&2
                ;;
        esac
    done

done

2) I removed hardening-wrapper and binutils-gold from my system. I set
   VERBOSE to 1 in debian/rules.

=> Linking protoc mysteriously does not fail anymore! (I had to enter
"r" a few times since the ld.bfd was being called with invalid options,
probably the build system was trying to probe what options it supports).

However, after a long build I got a different build failure:

g++ '-DENABLE_LOGGING_AND_PROFILING' '-DENABLE_DEBUGGER_SUPPORT' '-DENABLE_VMSTATE_TRACKING' '-DV8_TARGET_ARCH_ARM' '-DNO_TCMALLOC' '-DNO_HEAPCHECKER' '-DDISABLE_NACL' '-DCHROMIUM_BUILD' '-DENABLE_REMOTING=1' '-DUSE_PROPRIETARY_CODECS' '-DENABLE_GPU=1' '-DGLEW_MX' '-DENABLE_EGLIMAGE=1' '-DNDEBUG' '-DNVALGRIND' '-DDYNAMIC_ANNOTATIONS_ENABLED=0' -Iv8/src -Iv8/src/arm -pthread -fno-exceptions -Wno-unused-parameter -Wno-missing-field-initializers -D_FILE_OFFSET_BITS=64 -fvisibility=hidden -pipe -fPIC -fno-strict-aliasing -Wno-deprecated -Wno-format -fno-ident -fdata-sections -ffunction-sections -fomit-frame-pointer -O3 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -MMD -MF out/Release/.deps/out/Release/obj.host/v8_base/v8/src/arm/macro-assembler-arm.o.d.raw  -c -o out/Release/obj.host/v8_base/v8/src/arm/macro-assembler-arm.o v8/src/arm/macro-assembler-arm.cc
v8/src/arm/macro-assembler-arm.cc:61:3: error: #error "For thumb inter-working we require an architecture which supports blx"

This is with ctu.iuculano.it/gyp_0.1~svn917-1_all.deb in case it
matters. Full build log is attached.

This looks like a duplicate of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611518 -- why is
chromium now using embedded v8 again? The last mention of v8 in
changelog says "* Use libv8 system copy" but maybe this has been
reverted?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: chromium-browser_11.0.696.65~r84435-1_armel.build.xz
Type: application/octet-stream
Size: 174680 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-chromium-maint/attachments/20110517/12877aca/attachment-0001.obj>
-------------- next part --------------



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


More information about the Pkg-chromium-maint mailing list