Open Bug 1064665 Opened 12 years ago Updated 4 years ago

no makefile in intl/icu/target

Categories

(Firefox Build System :: General, defect)

x86
OpenBSD
defect

Tracking

(Not tracked)

People

(Reporter: gaston, Unassigned)

Details

I've seen it seemingly random since a while, but 100% reproducible when building 33.0b1 - fails in icu, with an empty intl/icu/target dir. Dunno where/when a makefile should be generated there, but i have nothing... gmake[4]: Entering directory '/usr/obj/ports/firefox-33.0beta1/build-amd64/intl/icu' gmake[4]: Nothing to be done for 'tools'. gmake[4]: Leaving directory '/usr/obj/ports/firefox-33.0beta1/build-amd64/intl/icu' if test -d ../../dist/bin/browser ; then touch ../../dist/bin/browser/.purgecaches ; fi if test -d ../../dist/bin/webapprt ; then touch ../../dist/bin/webapprt/.purgecaches ; fi gmake -j1 -C target STATIC_O=o GENRBOPTS='-kR' gmake[4]: Entering directory '/usr/obj/ports/firefox-33.0beta1/build-amd64/intl/icu/target' gmake[4]: *** No targets specified and no makefile found. Stop. gmake[4]: Leaving directory '/usr/obj/ports/firefox-33.0beta1/build-amd64/intl/icu/target' Makefile:66: recipe for target 'buildicu' failed gmake[3]: *** [buildicu] Error 2 any hints welcome
After digging a bit more, it seems running configure within 33.0b1 doesnt run configure for intl/icu, it directly goes to libffi. m-c: 1:46.30 updating cache ./config.cache 1:46.31 creating ./config.status 1:46.66 configuring in intl/icu/target 1:46.66 running /bin/sh /src/mozilla-central/intl/icu/source/configure --build=i386-unknown-openbsd5.6 --host=i386-unknown-openbsd5.6 --en able-static --disable-shared --disable-extras --disable-icuio --disable-layout --disable-tests --disable-samples --cache-file=/usr/obj/tmpf s/m-c/intl/icu/target/config.cache 1:46.86 configure: creating cache /usr/obj/tmpfs/m-c/intl/icu/target/config.cache 33.0b1: updating cache ./config.cache creating ./config.status configuring in js/src/ctypes/libffi i'm... puzzled.
Maybe it's accidentally getting skipped because of bug 1043268? You could try backing out that patch (and maybe the followup patch too) to see if it's related.
the intl api is enabled and exposed according to config.status, i dont use with-system-icu... after adding some debug echos to configure, it seems a subshell is supposed to be done to run the subconfigure, but the closing parenthesis is missing.. so maybe an autoconf issue. 29629 (export AR="$HOST_AR" 29630 export RANLIB="$HOST_RANLIB" 29631 export CC="$HOST_CC" 29632 export CXX="$HOST_CXX" 29633 export CPP="$HOST_CPP" 29634 export LD="$HOST_LD" 29635 export CFLAGS="$HOST_ICU_CFLAGS $HOST_OPTIMIZE_FLAGS" 29636 export CPPFLAGS="$ICU_CPPFLAGS" 29637 export CXXFLAGS="$HOST_ICU_CXXFLAGS $HOST_OPTIMIZE_FLAGS" 29638 export LDFLAGS="$HOST_LDFLAGS" 29639 ac_configure_args="$HOST_ICU_BUILD_OPTS" 29640 ac_configure_args="$ac_configure_args --enable-static --disable-shared --enable-extras=no --enable-icuio=no --enable-layout= no --enable-tests=no --enable-samples=no" 29641 trap '' EXIT 29642 for moz_config_dir in intl/icu/source:intl/icu/host; do 29643 case "$moz_config_dir" in 29644 *:*) *** 300 more lines then *** 30021 trap '[ "$?" != 0 ] && echo "------ config.log ------" && tail -n 25 config.log' EXIT 30022 30023 30024 ) || exit 1 30025 fi Again, i'm suspecting a gnu m4 vs bsd m4 issue... since in build/autoconf/icu.m4, theres: 180 (export AR="$HOST_AR" 181 export RANLIB="$HOST_RANLIB" 182 export CC="$HOST_CC" 183 export CXX="$HOST_CXX" 184 export CPP="$HOST_CPP" 185 export LD="$HOST_LD" 186 export CFLAGS="$HOST_ICU_CFLAGS $HOST_OPTIMIZE_FLAGS" 187 export CPPFLAGS="$ICU_CPPFLAGS" 188 export CXXFLAGS="$HOST_ICU_CXXFLAGS $HOST_OPTIMIZE_FLAGS" 189 export LDFLAGS="$HOST_LDFLAGS" 190 ac_configure_args="$HOST_ICU_BUILD_OPTS" 191 ac_configure_args="$ac_configure_args --enable-static --disable-shared --enable-extras=no --enable-icuio=no --enable-layout=no --enable-tests=no --enable-samples=no" 192 AC_OUTPUT_SUBDIRS(intl/icu/source:intl/icu/host) 193 ) || exit 1 i suspect AC_OUTPUT_SUBDIRS to behave strangely here in my infrastructure. Anyway, i suspect its a fallout from 1036645, mike, correct me if my analysis looks wrong.
(In reply to Michael Shal [:mshal] from comment #2) > Maybe it's accidentally getting skipped because of bug 1043268? You could > try backing out that patch (and maybe the followup patch too) to see if it's > related. i doubt that, since i'm starting from an empty objdir, there should be no reason for ignoring running subconfigures.. and bug 1043268 landed for 34.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.