Closed Bug 1314894 Opened 8 years ago Closed 8 years ago

configure: error: can not find install-sh or install.sh in ../build/autoconf ../../build/autoconf

Categories

(Firefox Build System :: General, defect)

x86
Windows
defect
Not set
normal

Tracking

(firefox52 fixed)

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: Paenglab, Assigned: glandium)

References

Details

Attachments

(1 file, 2 obsolete files)

At least Windows is busted by https://hg.mozilla.org/mozilla-central/rev/b6be0e9e3e1e (bug 1313306) with the error:

 checking for autoconf... C:/mozilla-build/msys/local/bin/autoconf-2.13

 Refreshing c:\builds\moz2_slave\tb-c-cen-w32-00000000000000000\build\mozilla\old-configure with C:/mozilla-build/msys/local/bin/autoconf-2.13

 creating cache ./config.cache
 *** Fix above errors and then restart with\
                "c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/mozmake.exe -f client.mk build"
 c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/client.mk:360: recipe for target 'configure' failed

 mozmake.exe[2]: Leaving directory 'c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build'

 c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/client.mk:374: recipe for target 'c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/objdir-tb/Makefile' failed

 mozmake.exe[1]: Leaving directory 'c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build'

 client.mk:217: recipe for target 'build' failed

 configure: error: can not find install-sh or install.sh in ../build/autoconf ../../build/autoconf
 DEBUG: This file contains any messages produced by compilers while

 DEBUG: running configure, to aid debugging if configure makes a mistake.

 DEBUG: 

 DEBUG: configure: error: can not find install-sh or install.sh in ../build/autoconf ../../build/autoconf

 ERROR: old-configure failed

 mozmake.exe[2]: *** [configure] Error 1

 mozmake.exe[1]: *** [c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/objdir-tb/Makefile] Error 2

mozmake.exe: *** [build] Error 2
Mike, do you know what the problem could be?
Flags: needinfo?(mh+mozilla)
I didn't land bug 1313670 without trying it first ;-)
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=aa5c4433a99227459212b78123298fbbf219bd8a
Same error there :-(

Aleth, can you please take a look, too.
Flags: needinfo?(aleth)
OS: Unspecified → Windows
Hardware: Unspecified → x86
I stand corrected, Richard reckons it's this one:
Bug 1313306, https://hg.mozilla.org/mozilla-central/rev/b6be0e9e3e1e
This will take some debugging on Windows to find the os.path.exists/isfile call which is failing.
Flags: needinfo?(aleth)
Just for the record: Richard confirmed the regression by backing out https://hg.mozilla.org/mozilla-central/rev/b6be0e9e3e1e locally.
(In reply to aleth [:aleth] from comment #5)
> This will take some debugging on Windows to find the os.path.exists/isfile
> call which is failing.
The one that's checking install-sh/install.sh? Must be something Windows and TB specific since the other platforms are building and so is FF (I assume).
Looks like the breaking change is this line https://hg.mozilla.org/mozilla-central/rev/b6be0e9e3e1e#l4.44
(In reply to aleth [:aleth] from comment #8)
> Looks like the breaking change is this line
> https://hg.mozilla.org/mozilla-central/rev/b6be0e9e3e1e#l4.44

Paenglab reported on IRC that this was a false lead due to not having clobbered.
You're sure?
I'm dumping out ${srcdir} in C:\mozilla-source\comm-central\mozilla\old-configure and I get |..| leading to error: can not find install-sh or install.sh in ../build/autoconf ../../build/autoconf

Correct would be to find the file in mozilla/build/autoconf.

Adding the line marked to C:\mozilla-source\comm-central\mozilla\old-configure
srcdir="../mozilla" <=== added this
ac_aux_dir=
for ac_dir in ${srcdir}/build/autoconf $srcdir/${srcdir}/build/autoconf; do
  if test -f $ac_dir/install-sh; then
gets me going. I'm five minutes into the build.

old-configure isn't source controlled, so it's generated somehow.
Sorry, "You're sure?" applied to comment #8. I think it's a false lead, too.
What's the difference between $srcdir and ${srcdir} - Sorry, I'm ignorant.
OK, here's the problem.

With the patch from bug 1313306, this is how old-configure is run:

ERROR: Running c:/mozilla-build/msys/bin/sh.exe 'c:\mozilla-source\comm-central\mozilla\old-configure' --enable-extensions=inspector --disable-sandbox --enable-calendar --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-tests --enable-debug --without-toolchain-prefix --enable-debug-symbols --enable-jemalloc --without-linux-headers --disable-warnings-as-errors --disable-js-shell --enable-sm-promise --disable-shared-js --disable-export-js --disable-instruments --disable-callgrind --disable-profiling --disable-vtune --disable-gc-trace --disable-perf --disable-more-deterministic --enable-ctypes --without-system-ffi

Backing out bug 1313306, this is how it's run:

ERROR: Running c:/mozilla-build/msys/bin/sh.exe c:/mozilla-source/comm-central/mozilla/old-configure --enable-extensions=inspector --disable-sandbox --enable-calendar --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-tests --enable-debug --without-toolchain-prefix --enable-debug-symbols --enable-jemalloc --without-linux-headers --disable-warnings-as-errors --disable-js-shell --enable-sm-promise --disable-shared-js --disable-export-js --disable-instruments --disable-callgrind --disable-profiling --disable-vtune --disable-gc-trace --disable-perf --disable-more-deterministic --enable-ctypes --without-system-ffi

old-configure works out srcdir here:

# Find the source files, if location was not specified.
if test -z "$srcdir"; then
  ac_srcdir_defaulted=yes
  # Try the directory containing this script, then its parent.
  ac_prog=$0
  ac_confdir=`echo $ac_prog|sed 's%/[^/][^/]*$%%'`
  test "x$ac_confdir" = "x$ac_prog" && ac_confdir=.
  srcdir=$ac_confdir
  if test ! -r $srcdir/$ac_unique_file; then
    srcdir=..
  fi
else
  ac_srcdir_defaulted=no
fi
if test ! -r $srcdir/$ac_unique_file; then
  if test "$ac_srcdir_defaulted" = yes; then
    { echo "configure: error: can not find sources in $ac_confdir or .." 1>&2; echo "configure: error: can not find sources in $ac_confdir or .." 1>&5; exit 1; }
  else
    { echo "configure: error: can not find sources in $srcdir" 1>&2; echo "configure: error: can not find sources in $srcdir" 1>&5; exit 1; }
  fi
fi
srcdir=`echo "${srcdir}" | sed 's%\([^/]\)/*$%\1%'`

Previously I saw c:/mozilla-source/comm-central/mozilla, now I see |..|.

So clearly the code that works out srcdir from the argument can't deal with
'c:\mozilla-source\comm-central\mozilla\old-configure'
but it could deal with
c:/mozilla-source/comm-central/mozilla/old-configure

So the change in bug 1313306 caused a change of argument here. The old-path passed in was Unix-style, now it's a Windows path.
Attached patch 1314894.patch (v1) (obsolete) — Splinter Review
Mike, I don't know whether this is the right fix and what "sandbox" is all about. I can only observe that old-configure is now called with, for example, 'c:\mozilla-source\comm-central\mozilla\old-configure', see comment #13. That prevents a correct srcdir being set.

Maybe you can suggest a better solution.
Attachment #8807264 - Flags: review?(mh+mozilla)
Attached patch 1314894.patch (v1a) (obsolete) — Splinter Review
Oops, fixed comment that was meant to go onto the previous line.
Attachment #8807264 - Attachment is obsolete: true
Attachment #8807264 - Flags: review?(mh+mozilla)
Attachment #8807266 - Flags: review?(mh+mozilla)
Blocks: 1313306
Product: Thunderbird → Core
Flags: needinfo?(mh+mozilla)
We need this landed on mozilla-central ASAP.
Bill, please ping Mike (:glandium). We're just the poor Thunderbird crowd whose builds on Windows don't work any more :-)

I'm not even sure that this is the right fix, but Mike can tell.
(In reply to Jorg K (GMT+1) from comment #19)
> Bill, please ping Mike (:glandium). We're just the poor Thunderbird crowd
> whose builds on Windows don't work any more :-)
> 
> I'm not even sure that this is the right fix, but Mike can tell.

But this also fixes my Firefox build and I suspect it fixes Chris Peirce's issue as well.  This is all in bug 1314934
	

.
Comment on attachment 8807346 [details]
Bug 1314894 - Avoid path changes from b6be0e9e3e1e.

https://reviewboard.mozilla.org/r/90522/#review90236
Attachment #8807346 - Flags: review?(cmanchester) → review+
Attachment #8807266 - Attachment is obsolete: true
Attachment #8807266 - Flags: review?(mh+mozilla)
Assignee: nobody → mh+mozilla
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/1a61a17b9986
Avoid path changes from b6be0e9e3e1e. r=chmanchester
https://hg.mozilla.org/mozilla-central/rev/1a61a17b9986
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: