Closed Bug 933123 Opened 11 years ago Closed 8 years ago

Unable to build spidermonkey when non-spidermonkey tree broken

Categories

(Firefox Build System :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sfink, Unassigned)

Details

Attachments

(2 files)

I can't get spidermonkey to build at all.

I have some changes in js/public/StructuredClone.h that break the build in other directories. I don't know if that's relevant.

./mach clobber; ./mach build fails, which is expected (StructuredClone.h)

But now I can't figure out how to build *just* spidermonkey. If I go to obj/js/src and do a make, I either get a failure to find a bunch of .a files like libmozzlib.a or something like that, or

/home/sfink/src/MI-GC/nsprpub/pr/src/md/unix/unix.c:3045: error: undefined reference to 'clock_gettime'

I also see it creating a file named libmozjs-None.so, which doesn't sound good.

The clock_gettime thing is fixed by adding -lrt to the link line, but even if I do that and remake, it recompiles everything again and retries the same link line (without -lrt, of course.)

If I run something like:

../../../js/src/configure  --enable-debug --disable-optimize --enable-gczeal --enable-application=browser --enable-threadsafe --without-intl-api --enable-ctypes --with-system-nspr --with-dist-dir=../../dist --prefix=/home/sfink/src/MI-GC/obj/dist --enable-jemalloc --cache-file=../.././config.cache --srcdir=/home/sfink/src/MI-GC/js/src

and then make, I get the same clock_gettime error.

If I create a new directory and run

../js/src/configure  --enable-debug --disable-optimize --enable-gczeal --enable-application=browser --enable-threadsafe --without-intl-api --enable-ctypes --with-system-nspr --enable-jemalloc --srcdir=/home/sfink/src/MI-GC/js/src 

and then make, I get that same libmozjs-None.so created, but a successful build. Ooh! A build! Yay! I can make progress now.
Attached file mozconfig
Attached patch Local changesSplinter Review
Rollup of all local changes. Base revision is ba5c76b30f29
Sample error for the .a problem:

Executing: c++ -o js -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wsign-compare -Wno-invalid-offsetof -Wcast-align -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DDEBUG -D_DEBUG -DTRACING -g -fno-omit-frame-pointer /home/sfink/src/MI-GC/obj/js/src/shell/tmp2WAcm8.list -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B ../build/unix/gold -Wl,-rpath-link,../../../dist/bin -Wl,-rpath-link,/home/sfink/src/MI-GC/obj/dist/lib -L../../../dist/bin -L../../../dist/lib -L/home/sfink/src/MI-GC/obj/dist/lib -lnspr4 -lplc4 -lplds4 ../libjs_static.a /home/sfink/src/MI-GC/obj/modules/zlib/src/libmozz.a -Wl,--whole-archive ../../../dist/lib/libmozglue.a ../../../dist/lib/libmemory.a -Wl,--no-whole-archive -rdynamic -lm -ldl
/home/sfink/src/MI-GC/obj/js/src/shell/tmp2WAcm8.list:
    INPUT("js.o")
    INPUT("jsheaptools.o")
    INPUT("jsoptparse.o")
    INPUT("../editline/editline.o")
    INPUT("../editline/sysunix.o")

c++: error: /home/sfink/src/MI-GC/obj/modules/zlib/src/libmozz.a: No such file or directory
c++: error: ../../../dist/lib/libmozglue.a: No such file or directory
c++: error: ../../../dist/lib/libmemory.a: No such file or directory
Note that the attached mozconfig uses --enable-shared-js but the above sample configure lines do not. I removed it to see if it helped. (It did not.)

The error message in comment 3 is from the original mozconfig options.
Well, if you run configure for a standalone js build at the same place you already had a js build for firefox, that's bound to fail, just because of config.cache. You can't really expect that to work.

The libmozjs-None.so thing, though, is fallout from bug 927073, and oversight on my part. Replacing
    AC_DEFINE_UNQUOTED(MOZILLA_SYMBOLVERSION,"$MOZILLA_SYMBOLVERSION")
with
    AC_SUBST(MOZILLA_SYMBOLVERSION)

in configure.in and js/src/configure.in should fix that.

So, other than that -None issue, what problem would you expect this bug to solve.
(In reply to Mike Hommey [:glandium] from comment #5)
> So, other than that -None issue, what problem would you expect this bug to
> solve.

I would expect one of the following:

  ./mach clobber
  ./mach build # Fails somewhere outside of js/src, but js binary gets built

or

  ./mach clobber
  ./mach build # Fails somewhere outside of js/src, which prevents the js binary from building
  cd obj/js/src
  make # builds js binary

I did the latter, but the make failed to build the js binary. There was no standalone configure involved. I only attempted that later, and yes, it's no big deal to me if that fails. I sometimes do that with a non-standalone tree when I want to change js configure options, and it would be nice if it continued to work, but I'm fine with losing it if it gets in the way.
or

  ./mach clobber
  ./mach build # Fails somewhere outside of js/src, which prevents the js binary from building
  ./mach build js/src # builds js binary

is ok too if running make in an objdir is problematic. (I tried; it also failed.)
Ok, once I fixed the outside-of-spidermonkey build breakage, the whole tree built with a toplevel |./mach build|. (It did *not* build with a toplevel |./mach build binaries|, but I'm never sure when that's expected to work.) Changing bug title accordingly.
Summary: Unable to build spidermonkey → Unable to build spidermonkey when non-spidermonkey tree broken
Ok, whatever this was, I'm guessing it's no longer relevant.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
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: