Last Comment Bug 692606 - clobber needed after changing --enable-jprof (or --enable-shared-js?)
: clobber needed after changing --enable-jprof (or --enable-shared-js?)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: unspecified
: x86_64 Linux
: -- normal (vote)
: mozilla10
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: clobber
  Show dependency treegraph
 
Reported: 2011-10-06 14:44 PDT by Steve Fink [:sfink] [:s:]
Modified: 2013-11-21 14:33 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Depend on mozilla-config.h (624 bytes, patch)
2011-10-06 15:09 PDT, Steve Fink [:sfink] [:s:]
mh+mozilla: review-
Details | Diff | Review
Depend on autoconf.mk (627 bytes, patch)
2011-10-06 15:17 PDT, Steve Fink [:sfink] [:s:]
mh+mozilla: review+
Details | Diff | Review

Description Steve Fink [:sfink] [:s:] 2011-10-06 14:44:38 PDT
I recently added --enable-jprof to my mozconfig and reran make -f client.mk. The resulting xpcshell and firefox binaries would not run. xpcshell spews out a couple of incomprehensible errors ("This should never happen!" or something like that.) firefox gave some sort of XRE load failure.

LD_DEBUG=libs showed that it was failing to resolve a pair of symbols in libxul.so -- but also that it was using /usr/lib64/xulrunner-1.9.2/libxul.so!

What ended up being the problem is that my dependentlibs.list was missing libjprof.so, so dlopen of obj/dist/bin/libxul.so failed, so it fell back to the system lib.

I kind of feel like the real problem is the opacity of XPCOM glue failures, but this bug is for the needs-clobber problem.
Comment 1 Gregory Szorc [:gps] 2011-10-06 14:58:05 PDT
Is it not an unwritten rule to blow away your objdir after modifying .mozconfig?
Comment 2 Steve Fink [:sfink] [:s:] 2011-10-06 15:09:48 PDT
Created attachment 565369 [details] [diff] [review]
Depend on mozilla-config.h

This fixes it for me. My first attempt, to depend on Makefile instead of Makefile.in, did not work. (I thought maybe the Makefile would get regenerated when mozconfig changed.)

I'm not claiming this is the best way. It only works because --enable-jprof does both AC_DEFINE(MOZ_JPROF) and AC_SUBST(MOZ_JPROF), and so toggling --enable-jprof changes both mozilla-config.h and the dependentlibs.list that gets created from executing the Makefile.

I really wanted to do a mv-if-diff type of thing (i.e., unconditionally generated dependentlibs.list but only update the timestamp if it changes), but I don't want to deal with doing that portably.
Comment 3 Mike Hommey [:glandium] 2011-10-06 15:13:47 PDT
Comment on attachment 565369 [details] [diff] [review]
Depend on mozilla-config.h

Review of attachment 565369 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/stub/Makefile.in
@@ +122,5 @@
>  include $(topsrcdir)/config/rules.mk
>  
>  libs:: $(FINAL_TARGET)/dependentlibs.list
>  
> +$(FINAL_TARGET)/dependentlibs.list: Makefile.in $(DEPTH)/mozilla-config.h

config/autoconf.mk would make more sense.
Comment 4 Steve Fink [:sfink] [:s:] 2011-10-06 15:17:26 PDT
Created attachment 565371 [details] [diff] [review]
Depend on autoconf.mk

Indeed it would. Darn, that's what I was originally thinking of, but I wasn't sure how to get to the objdir, and thought a .h file would be easier... which has exactly the same problem.
Comment 5 Steve Fink [:sfink] [:s:] 2011-10-11 13:33:43 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/8fae5a109fe2
Comment 6 Marco Bonardo [::mak] 2011-10-12 03:11:28 PDT
https://hg.mozilla.org/mozilla-central/rev/8fae5a109fe2

Note You need to log in before you can comment on or make changes to this bug.