TB3 fails to compile due to "libgkconraw_s.a" missing.
ISHIKAWA, Chiaki
This is a development version, fetched from comm-central.
OS: linux
Outline
Compilation and linking fails due to the following error regarding the
missing libgkconraw_s.a
make[6]: Entering directory
`/home/ishikawa/TB-3HG/objdir-tb3/mozilla/layout/build'
make[6]: *** No rule to make target
`../../content/media/raw/libgkconraw_s.a', needed by `libgklayout.so'.
Stop.
make[6]: Leaving directory
`/home/ishikawa/TB-3HG/objdir-tb3/mozilla/layout/build'
make[5]: *** [libs] Error 2
make[5]: Leaving directory `/home/ishikawa/TB-3HG/objdir-tb3/mozilla/layout'
make[4]: *** [libs_tier_platform] Error 2
make[4]: Leaving directory `/home/ishikawa/TB-3HG/objdir-tb3/mozilla'
make[3]: *** [tier_platform] Error 2
make[3]: Leaving directory `/home/ishikawa/TB-3HG/objdir-tb3/mozilla'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/ishikawa/TB-3HG/objdir-tb3/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/ishikawa/TB-3HG/objdir-tb3'
make: *** [build] Error 2
Outline of the problem:
The inclusion of the library is not protected by "ifdef MOZ_RAW" in
one Makefile.in under mozilla/content/media/Makefile.in
Details:
In mozilla/content/media/Makefile.in:
`raw' directory is only compiled when MOZ_RAW is defined:
76 ifdef MOZ_RAW
77 PARALLEL_DIRS += raw
78 endif
(Strange, my source tree doesn't seem to have `raw' directory. The
source is fetched from comm-central in the last few days.)
But mozilla/layout/build/Makefile.in
doesn't conditionalize the inclusion of libgkconraw_s.so with
MOZ_RAW. Note the contrast with the "ifdef MOZ_OGG" and "ifdef
MOZ_WEBM" above and below.
164
165 ifdef MOZ_OGG
166 SHARED_LIBRARY_LIBS += \
167 $(DEPTH)/media/libtheora/lib/$(LIB_PREFIX)theora.$(LIB_SUFFIX) \
168 $(DEPTH)/content/media/ogg/$(LIB_PREFIX)gkconogg_s.$(LIB_SUFFIX) \
169 $(NULL)
170 endif
171
172 SHARED_LIBRARY_LIBS += \
173
$(DEPTH)/content/media/raw/$(LIB_PREFIX)gkconraw_s.$(LIB_SUFFIX)\
174 $(NULL)
175
176 ifdef MOZ_WEBM
177 SHARED_LIBRARY_LIBS += \
178 $(DEPTH)/content/media/webm/$(LIB_PREFIX)gkconwebm_s.$(LIB_SUFFIX) \
179 $(DEPTH)/media/libnestegg/src/$(LIB_PREFIX)nestegg.$(LIB_SUFFIX) \
180 $(DEPTH)/media/libvpx/$(LIB_PREFIX)vpx.$(LIB_SUFFIX) \
181 $(NULL)
182 endif
183
First failed FIX:
Conditionalize ("ifdef MOZ_RAW") the inclusion of the libgkconraw_s.a
in mozilla/layout/build/Makefile.in
But this still failed.
I found out the reason
1. There is NO `raw' directory in my source tree (fetched from
comm-central), AND
2. somehow MOZ_RAW (=1) defined in mozilla/config (!?) Very strange.
Has anyone seen the same problem?
If MOZ_RAW is not defined, then I believe the compilation will succeed.
TIA
CI
my MOZCONFIG setting:
####
#### According to build hint web page,
#### I *need* MOZ_OBJDIR. Really?
#### If so, the build / configure script SHOULD WARN and DIE
#### before proceeding if I don't specify MOZ_OBJDIR.
#### It proceeded without complaining at all.
####
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb3
#
# OK, build/configure warns when I try to invoke make,
# AFTER I set the above variable.
# but IT IS TOO LATE.
# ***
# * Your source tree contains these files:
# * /extra/ishikawa/download/TB-3HG/30b2-src/Makefile
# * /extra/ishikawa/download/TB-3HG/30b2-src/config/autoconf.mk
# * This indicates that you previously built in the source tree.
# * A source tree build can confuse the separate objdir build.
# *
# * To clean up the source tree:
# * 1. cd /extra/ishikawa/download/TB-3HG/30b2-src
# * 2. gmake distclean
# ***
# *** Fix above errors and then restart with "make -f
client.mk build"
#
#
mk_add_options MOZ_CO_PROJECT=mail
ac_add_options --enable-application=mail
ac_add_options --enable-optimize
ac_add_options --disable-ldap
# added DEC 5
ac_add_options --disable-necko-wifi
ac_add_options --disable-tests
ac_add_options --enable-debug
# #ac_add_options --disable-debug
ac_add_options --enable-shared
# # ac_add_options --enable-ui-locale=ja
ac_add_options --enable-official-branding
ac_add_options --disable-crashreporter
### On the other hand,
### build / config complained that L10BASE was not specified...
###
### The following was required when I manually expanded the source
### files, AND then I need to download l10n package/dir separately???
### (BUT I am not sure which version of l10n I downloaded...)
# #
###ac_add_options --with-l10n-base=/home/ishikawa/TB-3HG/src/l10n
# # and it seems that we need to copy it manually.
ac_add_options --enable-default-toolkit=cairo-gtk2
###
###
# NO according to mozilla web page for TB2 #
### ac_add_options --enable-system-cairo
# BEGIN media/vide related bug?
ac_add_options --disable-ogg
ac_add_options --disable-wave
ac_add_options --disable-webm
ac_add_options --disable-necko-wifi
# END
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
# # mk_add_options MOZ_CO_LOCALES=ja
mk_add_options BUILD_MODULES=all
--
int main(void){int j=2010;/*(c)2010 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i = "@>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/*under GPL */
Mark Banner
> I found out the reason
> 1. There is NO `raw' directory in my source tree (fetched from
> comm-central), AND
Are you sure that your mozilla/ directory is up to date? i.e. did you
run client.py and/or do a separate pull and update in the mozilla/
directory.
What happens if you do "hg status" in the mozilla/ directory. Does it
show any missing files, or files with ? beside them?
Standard8
ISHIKAWA, Chiaki
> On 03/08/2010 22:22, ISHIKAWA, Chiaki wrote:http://www.tta.or.kr/English/new/external_relations/n-idterms.jsp
Thank you for your post.
Things are getting weired. Please read on.
I am fairly certain I ran python client.py checkout regularly.
The output of hg status in mozilla directory is as follows.
(This I did immediately after reading your post. This is important as
you may become aware later in this post.)
It shows some extra local files I created during debugging problems in
nsHelperAppDlg.js. But nothing serious showed up. Merge of
layout/build/Makefile.in
was the change I made regarding "ifdef MOZ_RAW"
ishikawa@debian-vm:~/TB-3HG/new-src$ cd mozilla
ishikawa@debian-vm:~/TB-3HG/new-src/mozilla$ hg status
M layout/build/Makefile.in
? dom/base/nsDOMClassInfo.cpp.orig
? toolkit/mozapps/downloads/nsHelperAppDlg.js.SAVED2
? toolkit/mozapps/downloads/nsHelperAppDlg.js.diff
?
toolkit/mozapps/downloads/nsHelperAppDlg.js.diff-white-space-change-ignored
? toolkit/mozapps/downloads/nsHelperAppDlg.js.orig
? toolkit/mozapps/downloads/nsHelperAppDlg.js.original
? toolkit/mozapps/downloads/nsHelperAppDlg.js.original-indented
? toolkit/mozapps/downloads/nsHelperAppDlg.js.saved
? toolkit/mozapps/downloads/nsHelperAppDlg.js.working
? toolkit/mozapps/downloads/t-diff.sh
? toolkit/mozapps/downloads/t.diff
ishikawa@debian-vm:~/TB-3HG/new-src/mozilla$
(Is it possible that if I pull from "comm-central", there may be a
timing window that some directories are not quite up-to-date as far as
files and directories under `mozilla' directory is concerned? I am not
still familiar with the directory and repository layout.)
*BUT*, I ran "python client.py checkout" one more time today (AFTER the
above "hg status" and
re-compiled.)
The compilation command is given at the end.
The result is, well, I am still waiting for it to finish.
But A BIG SURPRISE!
After TODAY's "python client.py checkout" I re-checked the source
directory. Then to my GREAT SURPRISE, the "raw" directory *IS* there
(!). Note that "raw" has been touched (created?) lately.
listing of ~/TB-3HG/new-src/mozilla/content/media/
drwxr-xr-x 7 ishikawa ishikawa 4096 2010-08-01 04:22 .
drwxr-xr-x 16 ishikawa ishikawa 4096 2010-05-16 00:59 ..
-rw-r--r-- 1 ishikawa ishikawa 2730 2010-08-01 04:22 Makefile.in
-rw-r--r-- 1 ishikawa ishikawa 4094 2010-08-01 04:22 VideoUtils.h
... many omissions ...
-rw-r--r-- 1 ishikawa ishikawa 17240 2010-08-01 04:22 nsMediaStream.h
drwxr-xr-x 2 ishikawa ishikawa 4096 2010-08-01 04:22 ogg
drwxr-xr-x 2 ishikawa ishikawa 4096 2010-08-01 04:22 raw <--- Huh?
drwxr-xr-x 3 ishikawa ishikawa 12288 2010-08-01 04:22 test
drwxr-xr-x 2 ishikawa ishikawa 4096 2010-08-01 04:22 wave
drwxr-xr-x 2 ishikawa ishikawa 4096 2010-06-18 03:46 webm
It WAS NOT THERE when I posted the previous article. The other four
directories (ogg, test, wave, and webm) were there. (And remember the
hg status output I showed?)
OK, I admit maybe I re-ran "python client.py checkout" again in the vain
hope to see if the compilation would succeed after another update and
forgot about it. But I am not sure now.
Something is fishy, though. Is there a delay of propagating the
change to comm-central repository? But it is hard to believe.
I thought update by hg is transaction-based and presumably
a consistent change posted by a developer will be seen full (or none at
all) by someone who is pulling update from the repository. Am I wrong?
(Ok, me thinks maybe the changes about this "raw" feature
was committed piece by piece intentionally by a developer or developers
Maybe, I fetched the update from the repository in the middle of such
piece-by-piece commits and Makefile.in and friends were in the new shape
while the "raw" directory itself was not still in the repository at
the moment I pulled the update. MAYBE. Otherwise, I can't explain this
strange state of affairs.)
Today's "python client.py checkout" produced the following output.
Is there something special about it?
ishikawa@debian-vm:~/TB-3HG/new-src$ python client.py checkout
Executing command: ['hg', 'pull', '-R', './.']
pulling from http://hg.mozilla.org/comm-central/
searching for changes
adding changesets
adding manifests
adding file changes
added 12 changesets with 31 changes to 31 files
(run 'hg update' to get a working copy)
Executing command: ['hg', 'update', '-r', 'default', '-R', './.']
31 files updated, 0 files merged, 1 files removed, 0 files unresolved
Updated to revision 8f588d5e7f8d6ae55e372e5bc34a7b83103fdfd9.
Executing command: ['hg', 'pull', '-R', './mozilla']
pulling from http://hg.mozilla.org/mozilla-central/
searching for changes
adding changesets
adding manifests
adding file changes
added 106 changesets with 352 changes to 280 files
(run 'hg update' to get a working copy)
Executing command: ['hg', 'update', '-r', 'default', '-R', './mozilla']
merging content/base/src/nsContentUtils.cpp
276 files updated, 1 files merged, 2 files removed, 0 files unresolved
Updated to revision 2f187db8f5f62b36c0ea2a9129530bf710312989.
Executing command: ['hg', 'pull', '-R', './mozilla/extensions/irc']
pulling from http://hg.mozilla.org/chatzilla/
searching for changes
no changes found
Executing command: ['hg', 'update', '-r', 'default', '-R',
'./mozilla/extensions/irc']
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Updated to revision ca24ef8091338740c4feb947858ba67de2f2fe33.
Executing command: ['hg', 'pull', '-R', './mozilla/extensions/inspector']
pulling from http://hg.mozilla.org/dom-inspector/
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 1 files
(run 'hg update' to get a working copy)
Executing command: ['hg', 'update', '-r', 'default', '-R',
'./mozilla/extensions/inspector']
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Updated to revision b6734423022bcf79dbf58bba4996a7954a1cc33a.
CVS checkout begin: 2010-08-04 17:43:21 UTC
Executing command: ['cvs', '-d',
':pserver:anon...@cvs-mirror.mozilla.org:/cvsroot', '-q', 'checkout',
'-P', '-r', 'LDAPCSDK_6_0_6D_MOZILLA_RTM', '-d', 'c-sdk',
'mozilla/directory/c-sdk']
CVS checkout end: 2010-08-04 17:43:24 UTC
Executing command: ['hg', 'pull', '-R', './mozilla/extensions/venkman']
pulling from http://hg.mozilla.org/venkman/
searching for changes
no changes found
Executing command: ['hg', 'update', '-r', 'default', '-R',
'./mozilla/extensions/venkman']
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Updated to revision 015647fa78683fbc2416d451cd24e58bc3ff41c6.
ishikawa@debian-vm:~/TB-3HG/new-src$ !./do-make.sh
(As I said a few times, it *seemed* to me that there is some strange
propagation/timing or a simple copy/move delay (?) to comm-central
repository from time to time. Later "python client.py checkout" have
seemed to solve the problems, but sometimes I had to re-create the local
repository from scratch.
Maybe just an artifact caused by these piece-by-piece
commits, etc. Maybe living in UTC+9 timezone may highlight such
ill-advised practice.)
I will report the OK/NG of the compilation itself hopefully tomorrow.
Until the compilation succeeds, I can't verify the fix for
nsHelperAppDlg.js, which has caused grief for a long time to many users,
it seems.
Thank you again for your comment.
CI
cf. My compilation command
---- begin do-make.sh
#
# do-make.sh
#
:
#
# MOZCONFIG needs to be an absolute path?
# Otherwise, it may be that the configure in subdirectories
# may fail to see it and falls back on ~/.mozconfig
#
set -vx
# make the messages into "unlocalized" ones for posting to newsgroups
and such
export LANG=C
export LC_ALL=C
export MOZCONFIG=~/TB-3HG/new-src/mozconfig-tb3
export CC="gcc -DDEBUG_4GB_CHECK"
make -j 2 -f client.mk $*
----- end quote
ISHIKAWA, Chiaki
object directory (?).
The seemingly new `raw' directory is not created in the object directory.
See at the end.
The compilation failed to the same problem.
OK, I think now I know the problem in more detail, or in more correct
viewpoint.
It may be that the `raw' directory WAS in the local source tree, all
right.
But somehow the logic to populate the object directory didn't work
for the newly created `raw' directory.
cf. ME_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb3
See `raw' directory is missing from the object directory in the
listing below . This is
probably the cause of the failure?
Listing of object directory:
/home/ishikawa/TB-3HG/objdir-tb3/mozilla/content/media:
drwxr-xr-x 8 ishikawa ishikawa 4096 2010-06-18 05:02 .
drwxr-xr-x 15 ishikawa ishikawa 4096 2010-02-11 02:49 ..
drwxr-xr-x 2 ishikawa ishikawa 4096 2010-05-16 03:01 .deps
-rw-r--r-- 1 ishikawa ishikawa 2799 2010-06-14 07:14 Makefile
-rw-r--r-- 1 ishikawa ishikawa 2291376 2010-06-18 05:02 libgkconmedia_s.a
-rw-r--r-- 1 ishikawa ishikawa 39032 2010-06-18 05:02 nsAudioStream.o
-rw-r--r-- 1 ishikawa ishikawa 325580 2010-06-18 05:01
nsBuiltinDecoder.o
-rw-r--r-- 1 ishikawa ishikawa 231140 2010-06-18 05:02
nsBuiltinDecoderReader.o
-rw-r--r-- 1 ishikawa ishikawa 393444 2010-06-18 05:02
nsBuiltinDecoderStateMachine.o
-rw-r--r-- 1 ishikawa ishikawa 407968 2010-06-18 05:01 nsMediaCache.o
-rw-r--r-- 1 ishikawa ishikawa 370728 2010-06-18 05:01 nsMediaDecoder.o
-rw-r--r-- 1 ishikawa ishikawa 494640 2010-06-18 05:01 nsMediaStream.o
drwxr-xr-x 3 ishikawa ishikawa 4096 2010-06-18 05:01 ogg
drwxr-xr-x 2 ishikawa ishikawa 4096 2009-12-05 08:48 test
drwxr-xr-x 5 ishikawa ishikawa 4096 2009-07-02 03:30 video
drwxr-xr-x 3 ishikawa ishikawa 4096 2010-06-18 05:01 wave
drwxr-xr-x 3 ishikawa ishikawa 4096 2010-06-18 05:01 webm
Note the missing `raw' directory. (Maybe I noticed this in my original
report. Now I am not sure which directory tree I checked :-( )
I would remove object directory completely, re-create the directory
afresh, and re-compile the source tree.
But I think the directory creation logic (inside the object tree) may
have a flaw somewhere. (Maybe it creates the directory only on the
first creation time and subsequent new directory is not created in the
object directory. Hmm... Maybe this is the reason why I sometimes had to
re-create all the source tree and start over...)
Or is there a special option to client.py to make sure that all the
directories are indeed reflected in the MOZ_OBJDIR ?
ISHIKAWA, Chiaki
I did the following just for a test.
I commented out this section in mozilla/layout/build/Makefile:
#
#SHARED_LIBRARY_LIBS += \
# $(DEPTH)/content/media/raw/$(LIB_PREFIX)gkconraw_s.$(LIB_SUFFIX)\
# $(NULL)
#endif
#
(ifdef MOZ_RAW didn't work as intended because configure still sets
MOZ_RAW unconditionally after the latest checkout yesterday.)
Then, after another "python client.py checkout" and
re-compilation WITHOUT starting from scratch by removing MOZ_OBJDIR,
the compilation succeeded. Hmm...
The `raw' directory still doesn't exist in the MOZ_OBJDIR,
objdir-tb3/mozilla/content/media/, while {ogg|test|video|wave|webm}
directories exist there.
I tried "make -f client.mk build" to see if this properly creates
`raw' directory in MOZ_OBJDIR. No, it didn't. So obviously without
commenting out the above section, compilation would fail in my
environment.
Now, all I can think of is that there may be a few flaws here.
- mozilla/layout/build/Makefile is referring to a library that should
not be included (under my environment where I am trying to make
TB3 without media support.)
- Or there is a logical flaw in Makefiles, etc. that fails the
creation `raw' directory in MOZ_OBJDIR/mozilla/content/media/, while
{ogg|test|video|wave|webm} exists. Probably the new `raw' directory
should be created so that mozilla/layout/build/Makefile can refer to
it.
I am not sure how a new directory that gets created in the middle of
development cycle is handled in the compilation framework of source
tree and separate object tree. It seems that such a new directory
doesn't get created automatically in object directory. I am going
to check if raw is created properly if object directory is deleted,
and the top-level object directory is created, and whole source tree
is re-compiled. I suspect it would (it SHOULD).
- But I am not sure if library under this `raw', presumably having
something to do with media support, should be unconditionally
included if media support is not built into TB3.
- So I suspect that MOZ_RAW in mozilla/configure should not be
blindly set.
As of now, mozilla/configure.in contains the following sequence.:
...
MOZ_OGG=1
MOZ_RAW=1
MOZ_SYDNEYAUDIO=
...
...
...
if test -n "$MOZ_NO_FAST_LOAD"; then
AC_DEFINE(MOZ_NO_FAST_LOAD)
fi
AC_SUBST(MOZ_RAW) <--- CI comment
AC_DEFINE(MOZ_RAW) <--- There is no condition!
dnl ========================================================
dnl = Disable Ogg Codecs
dnl ========================================================
MOZ_ARG_DISABLE_BOOL(ogg,
[ --disable-ogg Disable support for OGG media (Theora
video and Vorbis audio)
...
...
The above code results in the following in configure. Note that
MOZ_RAW is
set unconditionally.
if test -n "$MOZ_NO_FAST_LOAD"; then
cat >> confdefs.h <<\EOF
#define MOZ_NO_FAST_LOAD 1
EOF
fi
cat >> confdefs.h <<\EOF
#define MOZ_RAW 1
EOF
# Check whether --enable-ogg or --disable-ogg was given.
if test "${enable_ogg+set}" = set; then
enableval="$enable_ogg"
TIA
ishikawa
I removed MOZ_OBJDIR (../objdir-tb3) and re-create the top-most directory,
and recompiled. The compilation is proceeding, but the directories were not
quite re-generated as I expected at all. See long story at the end.
Short story:
I removed MOZ_OBJDIR (../objdir-tb3) and re-create the top-most directory,
and recompiled. The compilation is proceeding, but the directories were not
quite re-generated at all as I expected.
The compilation is proceeding, but when I check the directories, especially
'raw', I was surprised there were NO directories beneath
MOZ_OBJDIR/mozilla/content/media at all (!?)
There were no {ogg|test|video|wave|webm}, not to speak of 'raw'.
(I have disabled ogg, video, wave, webm by disable directives.)
I don't know exactly when these directories are made during compilation, but
I had thought they were created initially.
Maybe the compilation was not proceeding as far as ./mozilla directory.
Or are these directories {ogg|video|wave|webm} only created iif (if and only
if) they are required for compilation?
I compiled TB3 when these were enabled before and later disabled them. That
seems to explain why I saw ogg, webm, wave, etc. before.
In any case, the logic and procedure of creating NEW directories in
MOZ_OBJDIR may require investigation.
As I see it, a newly created directory put into the source tree repository
during a development cycle doesn't seem to be have its mirror/shadow created
in already existing MOZ_OBJDIR, leading to inconsistency. (And re-compiling
the WHOLE tree just to get this sorted out takes time, long enough time to
discourage would be developers. This is very bad IMHO.)
TIA