Opened 11 years ago
Closed 4 years ago
#41924 closed defect (fixed)
v8 @3.23.15: build fails on lion buildslave and icu confusion
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.1 |
Keywords: | Cc: | neverpanic (Clemens Lang), Raptor007 (Raptor007) | |
Port: | v8 |
Description
v8 @3.23.15 fails to build on the lion buildslave: https://build.macports.org/builders/buildports-lion-x86_64/builds/16461
v8 declares a dependency on the icu port (currently @51.2, indicating it wants to use MacPorts icu), but then fetches its own copy of icu46 (#41677, indicating it wants to use its own copy), then builds with -Duse_system_icu=1
(indicating it wants to use MacPorts icu), then builds its own copy (indicating it wants to use its own copy), apparently for the wrong architecture (can't tell what architecture it used, because the build system uses silent rules), then finally it fails when trying to link mksnapshot with the wrong-arch icu:
LINK(host) /opt/local/var/macports/build/_opt_mports_dports_lang_v8/v8/work/v8-3.23.15/out/x64.release/mksnapshot.x64 ld: warning: ignoring file /opt/local/var/macports/build/_opt_mports_dports_lang_v8/v8/work/v8-3.23.15/out/x64.release/obj.host/third_party/icu/libicuuc.dylib, file was built for unsupported file format ( 0xce 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 0 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_mports_dports_lang_v8/v8/work/v8-3.23.15/out/x64.release/obj.host/third_party/icu/libicuuc.dylib ld: warning: ignoring file /opt/local/var/macports/build/_opt_mports_dports_lang_v8/v8/work/v8-3.23.15/out/x64.release/obj.host/third_party/icu/libicui18n.dylib, file was built for unsupported file format ( 0xce 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 0 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (x86_64): /opt/local/var/macports/build/_opt_mports_dports_lang_v8/v8/work/v8-3.23.15/out/x64.release/obj.host/third_party/icu/libicui18n.dylib Undefined symbols for architecture x86_64: "icu_46::DateFormat::getAvailableLocales(int&)", referenced from: v8::internal::Runtime_AvailableLocalesOf(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.x64.a(runtime.o) "icu_46::Formattable::Formattable()", referenced from: v8::internal::Runtime_InternalNumberParse(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.x64.a(runtime.o) "icu_46::Formattable::~Formattable()", referenced from: v8::internal::Runtime_InternalNumberParse(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.x64.a(runtime.o) "icu_46::StringPiece::StringPiece(char const*)", referenced from: v8::internal::Runtime_InternalDateParse(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.x64.a(runtime.o) v8::internal::Runtime_InternalNumberParse(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.x64.a(runtime.o) v8::internal::(anonymous namespace)::ExtractStringSetting(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSObject>, char const*, icu_46::UnicodeString*) in libv8_base.x64.a(i18n.o)
The magic number 0xce 0xfa 0xed 0xfe, however, seems to indicate that the icu that got built is a 32-bit i386 binary, which would be wrong.
Change History (3)
comment:1 Changed 10 years ago by Raptor007 (Raptor007)
Cc: | blair@… added |
---|
comment:2 Changed 8 years ago by kurthindenburg (Kurt Hindenburg)
Owner: | changed from frodwith@… to macports-tickets@… |
---|---|
Status: | new → assigned |
comment:3 Changed 4 years ago by chrstphrchvz (Christopher Chavez)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Cc Me!