Has anyone compiled TB3 or Firefox lately under Debian GNU/Linux successfully?
ISHIKAWA, Chiaki
(I changed the subject, and added mozilla.dev.platform )
My development environment is Debian GNU/Linux.
I tried to compile TB3 lately and encountered the problem, specifically
noted below:
>/usr/bin/ld: ../xre/glxtest.o: relocation R_386_GOTOFF against undefined
> hidden symbol `mozilla::widget::glxtest_pid' can not be used when making
> a shared object
I am afraid that ld stopped immediately after this error, and
it seems there are tons of such hidden symbols inside (nested)
namescope(s) and ld generates many errors when I tinkered with the
glxtest.cpp to remove the reference to the offending
mozilla::widge::glxtest_pid in mozilla/widget/src/xpwidgets/GlxInfoX11.cpp
I thought the problem was limited to only to this particular symbol, was
I wrong...
It seems that the tool chain on Debian GNU/Linux may have issues
with the current TB3 (and Firefox) source files as far as the subtle
scope issues.
$ g++ --version
g++ (Debian 4.5.3-1) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
There was a thread concerning build under Debian in November, 2010:
Re: Build under Debian GNU/Linux(?) Stubcalls.cpp fails to compile.
Back then it was suggested:
Mike Shaver <mike....@gmail.com> wrote:
> On Tue, Nov 23, 2010 at 11:27 AM, ISHIKAWA, Chiaki
> <ishi...@yk.rim.or.jp> wrote:
>> > Maybe we should put this bugzilla and
>> > even ask for the code modification for supportning more build platforms
>> > just in case.
> I thought we fixed this before b7, but maybe the workaround for the
> gcc bug in that version of Debian didn't make it. Mike Hommey might
> know, I tihnk he follows this group.
>
> Can you try the latest mozilla-central trunk?
>
> Mike
The latest code is taken from comm-central and mozilla-central using
"hg". So the problem is clearly there again now.
Has there anyone who has compiled TB3 (or FF4?) successfully under
Debian GNU/Linux lately? I am using squeeze now.
BTW, what is the preferred choice of linux distribution for compilation
among TB3 developers? (But I think due to the use of shared
libraries,someone has to make sure that TB3 compiles under Debian.
Otherwise there could be shared library incompatibilities that will be
only found out when someone runs TB3 under Debian for the first time...
I really need to fix a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=429827
This bug hits me every so often. (I am using a NFS mount for one of my
often used work area and run TB3 remotely from another machine to begin
with. I admit this setup may not be common, but not so rare I suspect.)
But for more than half a year, I have not been able to compile TB3
adequately and can't tinker with bug fixing at all :-(
TIA
(2011/06/01 11:33), ISHIKAWA, Chiaki wrote:
> Hi,
> I have a couple of PCs in different geographical locations.
>
> (1) On one PC, I checked out the latest TB3 on one PC using git bundle, but
> somehow compilation could not proceed. The reason seems to
> be l10n directory is missing. I recall I copied this using cvs command,
> and used the same command to copy it from mozilla cvs server.
> But cvs command fails due to "duplicate key found" errors, and it seems
> that it is related to corrupted cache data on cvs server side.
> Has the means to obtain l10n change?
>
> If not, can someone look at the CVS server and clear the cache?
> According to some articles I found using google, this is a server side
> problem and the corrupted cache needs to be removed.
>
> (2) On the other PC, I have been updating older hg copies for some
> months, and on this PC, I could compile the latest checkout up to a point.
>
> AT the end of libxul creation, I get the error as follows.
> hidden symbol may be related to a bug in ld/asm, etc. toolchain.
> (I am using Debian GNU/Linux.)
> $ ld --version
> GNU ld (GNU Binutils for Debian) 2.21.0.20110327
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later
> version.
> This program has absolutely no warranty.
>
> ishikawa@debian-vm:~/TB-3HG/new-src$ as --version
> GNU assembler (GNU Binutils for Debian) 2.21.0.20110327
> Copyright 2011 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `i486-linux-gnu'.
>
> But the error about nsTelemetryModule_NSModule is puzzling.
> This name is referenced through the following define in
> mozilla/toolkit/library/nsStaticXULComponents.cpp
> (I am pasting from mxr.mozilla.org cross reference listing.)
> It is appened at the end. So is it possible that only the reference is
> put in this file, but the file where it is defined is not put in the hg
> repository yet?
>
> 235 #define XUL_MODULES \
> 236 MODULE(nsUConvModule) \
> 237 MODULE(nsI18nModule) \
> 238 MODULE(nsChardetModule) \
> .... [omissions] ....
> 285 MOZ_APP_COMPONENT_MODULES \
> 286 MODULE(nsTelemetryModule) \
> 287 /* end of list */
> 288
>
> The excerpted error listing:
>
> /home/ishikawa/TB-3HG/objdir-tb3/mozilla/config/nsinstall -D
> ../../dist/sdk/lib
> rm -f libxul.so
> /usr/bin/python2.6
> /home/ishikawa/TB-3HG/new-src/mozilla/config/pythonpath.py
> -I../../config
> /home/ishikawa/TB-3HG/new-src/mozilla/config/expandlibs_exec.py
> --uselist -- /usr/bin/g++ -DDEBUG_4GB_CHECK -fno-rtti -fno-exceptions
> -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
> -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
> -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic
> -Wno-long-long -fno-strict-aliasing -fshort-wchar -pthread -pipe
> -DNDEBUG -DTRIMMED -g -O3 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs
> -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o
> nsBidiUtils.o nsRDFResource.o -lpthread
> -Wl,-rpath-link,/home/ishikawa/TB-3HG/objdir-tb3/mozilla/dist/bin
> -Wl,-rpath-link,/usr/local/lib ../../toolkit/xre/libxulapp_s.a
> ../../staticlib/components/libnecko.a
> ../../staticlib/components/libuconv.a
> ../../staticlib/components/libi18n.a
> ../../staticlib/components/libchardet.a
> ../../staticlib/components/libjar50.a
> ../../staticlib/components/libstartupcache.a
> ../../staticlib/components/libpref.a
> ../../staticlib/components/libhtmlpars.a
> ../../staticlib/components/libimglib2.a
> ../../staticlib/components/libgkgfx.a
> ../../staticlib/components/libgklayout.a
> ../../staticlib/components/libdocshell.a
> ../../staticlib/components/libembedcomponents.a
> ../../staticlib/components/libwebbrwsr.a
> ../../staticlib/components/libnsappshell.a
> ../../staticlib/components/libtxmgr.a
> ../../staticlib/components/libcommandlines.a
> ../../staticlib/components/libtoolkitcomps.a
> ../../staticlib/components/libpipboot.a
> ../../staticlib/components/libpipnss.a
> ../../staticlib/components/libappcomps.a
> ../../staticlib/components/libcomposer.a
> ../../staticlib/components/libjetpack_s.a
> ../../staticlib/components/libjsctypes.a
> ../../staticlib/components/libjsperf.a
> ../../staticlib/components/libgkplugin.a
> ../../staticlib/components/libunixproxy.a
> ../../staticlib/components/libjsd.a
> ../../staticlib/components/libautoconfig.a
> ../../staticlib/components/libauth.a
> ../../staticlib/components/libcookie.a
> ../../staticlib/components/libpermissions.a
> ../../staticlib/components/libuniversalchardet.a
> ../../staticlib/components/librdf.a
> ../../staticlib/components/libwindowds.a
> ../../staticlib/components/libfileview.a
> ../../staticlib/components/libstoragecomps.a
> ../../staticlib/components/libplaces.a
> ../../staticlib/components/libmork.a
> ../../staticlib/components/libtkautocomplete.a
> ../../staticlib/components/libsatchel.a
> ../../staticlib/components/libpippki.a
> ../../staticlib/components/libwidget_gtk2.a
> ../../staticlib/components/libsystem-pref.a
> ../../staticlib/components/libimgicon.a
> ../../staticlib/components/libaccessibility.a
> ../../staticlib/components/libremoteservice.a
> ../../staticlib/components/libspellchecker.a
> ../../staticlib/components/libzipwriter.a
> ../../staticlib/components/libservices-crypto.a
> ../../staticlib/components/libxpautocomplete.a
> ../../staticlib/components/libmailcomps.a
> ../../staticlib/components/libmail.a
> ../../staticlib/components/libmsgsmime.a
> ../../staticlib/components/libimport.a
> ../../staticlib/components/libmozldap.a ../../staticlib/libjsipc_s.a
> ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a
> ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a
> ../../staticlib/libipcshell_s.a ../../staticlib/libgfxipc_s.a
> ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a
> ../../staticlib/libchromium_s.a ../../staticlib/libmozreg_s.a
> ../../staticlib/libmorkreader_s.a ../../staticlib/libgtkxtbin.a
> ../../staticlib/libthebes.a ../../staticlib/libycbcr.a
> ../../staticlib/libangle.a ../../dist/lib/libmozsqlite3.a
> -L../../dist/bin -L../../dist/lib ../../jpeg/libmozjpeg.a
> ../../modules/libimg/png/libmozpng.a ../../gfx/qcms/libmozqcms.a
> /home/ishikawa/TB-3HG/objdir-tb3/mozilla/dist/lib/libjs_static.a
> -L../../dist/bin -L../../dist/lib -lcrmf -lsmime3 -lssl3 -lnss3
> -lnssutil3 ../../gfx/cairo/cairo/src/libmozcairo.a
> ../../gfx/cairo/libpixman/src/libmozlibpixman.a -lXrender -lfreetype
> -lfontconfig ../../gfx/harfbuzz/src/libmozharfbuzz.a
> ../../gfx/ots/src/libmozots.a -L../../dist/bin -L../../dist/lib -lldap60
> -lprldap60 -lldif60 ../../modules/zlib/src/libmozz.a -lrt
> -L../../dist/bin -L../../dist/lib
> -L/home/ishikawa/TB-3HG/objdir-tb3/mozilla/dist/lib -lplds4 -lplc4
> -lnspr4 -lpthread -ldl ../../dist/lib/libmozalloc.a -ldbus-1 -lpthread
> -lrt -lX11 -lXext -pthread -lpangoft2-1.0 -lfreetype -lfontconfig
> -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0
> -lgthread-2.0 -lrt -lglib-2.0 -pthread -lgtk-x11-2.0 -latk-1.0
> -lgio-2.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lgdk-x11-2.0
> -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lpango-1.0 -lcairo -lgmodule-2.0
> -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lXt -lgthread-2.0
> -lfreetype -lz -ldl -lrt
> nsStaticXULComponents.o:(.data.rel.ro+0xe0): undefined reference to
> `nsTelemetryModule_NSModule'
> ../xre/glxtest.o: In function `fire_glxtest_process()':
> /home/ishikawa/TB-3HG/new-src/mozilla/toolkit/xre/glxtest.cpp:241:
> undefined reference to `mozilla::widget::glxtest_pid'
> /usr/bin/ld: ../xre/glxtest.o: relocation R_386_GOTOFF against undefined
> hidden symbol `mozilla::widget::glxtest_pid' can not be used when making
> a shared object
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> make[5]: *** [libxul.so] Error 1
>
> mozconfig content: On this machine, somehow, I don't seem to need l10n
> directory. What gives?
>
> ishikawa@debian-vm:~/TB-3HG/new-src$ cat mozconfig-tb3
> ####
> #### 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
> #
> #
> # suddenly --enable-debug starts to work for TB3 build around October
> 2010 timeframe!
> # But that caused ld to use up very large virtual memory
> # when linking libxul.so? and the final binary.
> #
> ac_add_options --disable-debug
> # ac_add_options --enable-debug
>
> ac_add_options --enable-shared
>
> # # ac_add_options --enable-ui-locale=ja
> ac_add_options --enable-official-branding
> ac_add_options --disable-crashreporter
>
> ac_add_options --disable-libjpeg-turbo
>
> ### 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/video related bug?
> ac_add_options --disable-ogg
> ac_add_options --disable-wave
> ac_add_options --disable-webm
> ac_add_options --disable-necko-wifi
>
> ac_add_options --disable-raw
>
> # ac_add_options --disable-ldap
> # 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
>
> # suddenly -j4 starts to work in Sept/Oct 2010
> # timeframe, and it sort of makes searching for
> # compilation errors and warnings difficult. So
> # I disabled it for now.
> # reenabled on May, 2011
> mk_add_options MOZ_MAKE_FLAGS="-j4"
>
>
> TIA
>
> PS: it has been months since I came close to compiling TB3 successfully
> on my Debian GNU/Linux installation. Since last September I could not
> compile TB3 at all due to some changes in the source code, Debian's tool
> chains were not quite compatible with the newer source, etc.
> I think the upgrade of Debian to the new release (lenny -> squeeze) this
> Spring has made it possible to tackle most of the problem now, and I am
> facing the minor (?) issues above before I can continue fixing
> some problems I reported to bugzilla. Wonderful, erh?
>
>
> The most notable bug is the silent failure [without any visible
> notification] to save attachment to a non-writable directory when you
> choose save after LEFT-clicking on the attachment.
>
> Funny, I just found out a few days ago that if someone sends me an HTML
> mail and if that contains a jpeg figure, and I can click on that jpeg
> figure (RIGHT-clicking) and then save it to a file. In this case, TB3
> duly notified me if I try to save the jpeg image to a non-writable
> directory saying the directoy can't be modified, change the property of
> the directory (actually it says folder, I think), and suggest changing
> the property (does it mean write permission?) or try saving it to a
> different location!
> Anyway, when I realize there is ANOTHER path through which something is
> saved to a disk, and at least one path reports the problem correctly,
> I thought maybe I can look at the path invoked when saving an image file
> from HTML file to correct the general attachment-saving path, and thus
> renewed interest to try to compile TB3 on Debian GNU/Linux.
> (I said "ANOTHER path" above because LEFT-clicking and RIGHT-clicking on
> the attachment invokes two different paths (one mostly written in
> Javascript, the other in cpp, and I was amused to see another possible
> path here.)
>
Justin Dolske
> My development environment is Debian GNU/Linux.
>
> I tried to compile TB3 lately and encountered the problem, specifically
> noted below:
Thunderbird 3? Or trunk (from Hg)?
>> ishikawa@debian-vm:~/TB-3HG/new-src$ cat mozconfig-tb3
>> [...]
There's a lot of options in your mozconfig, and that's often the path to
problems. Although I don't see anything _obvious_, I'd suggest starting
simple... See https://developer.mozilla.org/En/Simple_build
Once you get a basic build of Firefox working, then play with options if
really needed.
If it's still not working, either there's something odd about your
system or there's something about that Debian version's toolchain that's
unhappy with the Mozilla source. Debugging that would be good for others
(or maybe it's a known issue? Paging glandium...). Another idea, if you
just want to get the build going so you can work on the bug you're
trying to fix, would be to install a known-to-work Linux release in a
VM, and build there. I hate to suggest it, but at least it's a
likely-to-work option!
Justin
Joshua Cranmer
> Hi,
> (I changed the subject, and added mozilla.dev.platform )
>
> My development environment is Debian GNU/Linux.
>
> I tried to compile TB3 lately and encountered the problem, specifically
> noted below:
>
>> /usr/bin/ld: ../xre/glxtest.o: relocation R_386_GOTOFF against undefined
>> hidden symbol `mozilla::widget::glxtest_pid' can not be used when making
>> a shared object
>
using? I've found that clobbering and/or using different gcc/g++
toolchains gets this error to go away.
ishikawa
e-mail follow-ups.
Short answer: SUCCESS
On one PC, after removing the old OBJDIR (as suggested by an e-mail
follow-up) and letting make re-create it, and using a simplified
MOZCONFIG, I saw compilation/linking succeeded(!). And to my surprise,
running compilation/linking using the hand-crafted complex MOZCONFIG
after this succeeded also (!!)
- So there may be some files inside OBJDIR that are not quite
well-updated or re-created within the current configure/Makefile.in
and its recreation procedures? It seems that removing OBJDIR
completely solved this issue.
- After a successful compilation/linking, I verified the resulting
binary started up, and quit. Then I used the my original MOZCONFIG,
again after removing the OBJDIR, and tried compilation. A
welcome surprise: the compilation/linking succeeded and the
resulting binary started up successfully.
- I am afraid clean/clobber didn't seem to help at all it in my
particular case. I tried it a few times in the days leading up to
yesterday's efforts. So removing OBJDIR completely seemed to help
it. I wonder why :-(
I hasten to add that I have been keeping HG repository on one of the
PCs since early last year (or the end of the year before.), and have
been updating it on one of the PCs. So between the last successful
compilation and yesterday, the compilation/linking framework may have
gone through a few major changes which necessitate the complete
removal of OBJDIR to fix for issues which simple clean/clobber can't
handle.
As a comparative information, on the other PC, I have been unable to
re-create HG repository due to mysterious clone error, and thus used
hg bundle to re-create it in the last few days and updated it
again. (Beware: it takes several hours to re-create the HG repository
and update it to current state.) There the same compilation error was
seen. It is the (almost) same version Debian GNU/Linux, but due to the
timing of package update and inclusion of testing repository (done
yesterday), the toolchain is now slightly newer on the other PC. [Now
the toolchain version may seem not the culprit for errors I saw.]
It is possible that the OBJDIR may have contained old cruft that caused
the problems, BUG AGAIN, during the debugging efforts, I distinctively
recall that I removed it once or twice!? Hmm...
However, I am a little stunned that my complex MOZCONFIG works NOW.
Can it be that I need to run compilation ONCE using the minimum
MOZCONFIG. And something WITHIN SRCDIR changes to the better? Hard to
believe, but I am investigating more. (Sure on the PC where the
compilation finally succeeded, I remember I did some tweaks to
configure files to make it work successfully with fontconfig library
or something before. So many suspects to chase after...)
But it is great to be able to work on the real bug I want to fix
finally(!): I verified that the bug is still there in the newly
produced binary from TB Trunk (HG) version :-)
Thank you for the tips. The comment from Mike Hommey (in
mozilla.dev.builds) stating that his Debian GNU/Linux can compile some
versions of FF and TB3.1 lately was very encouraging. That made me to
try one more time, and I succeeded after OBJDIR was removed and simple
mozconfig was tried!
More Background and to answer the follow-up questions.
Justin Dolske wrote:
> Thunderbird 3? Or trunk (from Hg)?
- The source code: trunk from hg repositories
Joshua Cranmer wrote:
>Are you building on a 64-bit system? Which version of gcc/g++ are you
>using? I've found that clobbering and/or using different gcc/g++
>toolchains gets this error to go away.
- It seems that sometimes clobber is not enough, and surgical removal
of OBJDIR may be in order :-(
- I am on 32 bit system.
Linux debian-vbox-ci 2.6.38-2-686 #1 SMP Sun May 8 14:49:45 UTC 2011 i686
GNU/Linux
sizeof(int*) is 4, I just checked by compiling a small program just
to be sure.
- Relevant Tool versions (Debian)
GCC, G++, LD, AS version below.
Before After
----------------------------------------
gcc Debian 4.5.2-8 Debian 4.5.3-1
g++ Debian 4.5.2-8 Debian 4.5.3-1
ld 2.21.0.20110327 2.21.51.20110523*
as 2.21.0.20110327 2.21.51.20110523*
Before/After: Yesterday, on one of the PC's, I added testing
(bleeding edge?) repository for the Debian packages and upgraded
all the tools and the version of the above tools changed. ld, as
are now newer than the version on the other PC, which doesn't
specify the testing repository. (gcc, g++ were already 4.5.3 on
the other PC where compilation/linking also failed due to the same
reason PREVIOUSLY. There the compilation succeeded NOW as reported at
the top of this article. so maybe the "Before" versions are good
enough, and there are other reasons for the failure I saw.) I was
going to report the compilation/linking result using "After"
versions on a PC, but it ran out of file space this morning :-(
- Simplified mozconfig: Now I am using the following. The complex one
which I used was to avoid compiling/linking audio/video features
into TB3 (a mail client).
# to speed up for compilation test
ac_add_options --disable-tests
# to reduce size to save link time
ac_add_options --disable-debug
# YASM is not the latest.
ac_add_options --disable-libjpeg-turbo
#
ac_add_options --disable-crashreporter
ac_add_options --enable-application=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb3
# USE THIS ONLY IF NOT ON WINDOWS! Parallel compilation on Windows is
# unreliable now due to bug 524149.
mk_add_options MOZ_MAKE_FLAGS="-j4"
--disable-libjpeg-turbo : I don't have the latest version of yasm
to compile libjpeg turbo version.
(Debian doesn't offer it as stock package it seems. My local version
is 0.8.something.)
--disable-crashreporter is to avoid installing libcurl-dev, which
now forces me to choose one from three variants after testing
repository is included. :-(
cf.
# aptitude install libcurl-dev
"libcurl-dev" is a virtual package provided by:
libcurl4-openssl-dev libcurl4-nss-dev libcurl4-gnutls-dev
You must choose one to install.
No packages will be installed, upgraded, or removed.
My guess is that libcurl4-openssl-dev must be the one, since openssl
seems to be used by TB3, but I just skipped it for now.
One one PC, using the "Before" versions of LD, AS, I could
compile and link TB trunk as reported at the beginning.
On the other PC, using "After" versions of tool chain, I started the
compilation, but at the linking phase of libxul, the system ran out of
file space this morning. It looks we need a couple of GBs (plus maybe
another GB?) for storing the HG repository, and OBJDIR (?).
On the other PC, where the compilation/linking succeeded, I noticed the
linking of libxul takes a long time, and used up close to 1.25-1.5 GB RAM.
During that time, I noticed a heavy paging activity, and linking seemed to
take a long time. So allocating large amount of RAM to VM is
advised. Yes, I am using VM on a few PCs, but my old e-mails live on
native Debian GNU/Linux installation and an old native Fedora installation
for work. Anyway, I am re-running the compilation after removing the
OBJDIR again, and making sure there is enough file space room for the
next compilation.]
So morale of the story seems: when in doubt, remove OBJDIR and
re-create it (?)
But it sure takes time to do the compilation/linking again...
TIA
PS: I am not entirely sure why two copies of otherwise identical
Debian GNU/Linux behaved differently as far as "hg clone" was
concerned. Actually, this hampered my debugging effort so far.
The usage explanation of "hg bundle" in one of the mozilla web page
mentions that the bundle was prepared in the case of network
problem. I think there are two types of network problems: one near the
client-side, and the one near the server-side. I suspect a server side
problem for this constant "hg clone" failure in my own case.
Why do I think so? One PC ran it successfully over 12 months of time
more or less when I needed it, but the other PC failed it constantly
since sometime last summer. The failed PC is connected to a rather too
good network infrastructure in an office district, and can put a heavy
network demand on servers, and presumably the hg server could not pump
out enough data in time. The other PC, on which hg clone has been
successful, is connected to a mass-market consumer-type network
infrastructure and didn't put too much load on the hg server as the other PC
could. But this is pure
guess. Unless someone takes a look at the system log of the hg server,
and find some incriminating messages there, we won't know for sure.
Maybe a router or something got replaced last summer in a data center
where hg server is located (?).
Where should such hg server-related issues be discussed?
ISHIKAWA, Chiaki
I used the following simplified MOZCONFIG.
--- minimalist mozconfig-tb3
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-libjpeg-turbo
ac_add_options --disable-crashreporter
ac_add_options --enable-application=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb3
# USE THIS ONLY IF NOT ON WINDOWS! Parallel compilation on Windows is
# unreliable now due to bug 524149.
mk_add_options MOZ_MAKE_FLAGS="-j4"
There is one thing that puzzled me. When I started TB trunk (from HG),
it printed the following message on the invoking console:
ishikawa@debian-vbox-ci:/extra/ishikawa/download/TB-3HG/comm-central$
../objdir-tb3/mozilla/dist/bin/thunderbird
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is
enabled for this VM.
failed to create drawable <--- This message was also on the other PC.
ishikawa@debian-vbox-ci:/extra/ishikawa/download/TB-3HG/comm-central$
Wny on earth does TB, a mail client, requires 3D acceleration (OpenGL)?
Otherwise, the compilation succeeded. The compilation using the complex
MOZCONFIG on this PC has not been tried yet, but it probably works after
OBJDIR removal.
TIA.
Tony Mechelynck
[...]
> Wny on earth does TB, a mail client, requires 3D acceleration (OpenGL)?
Thunderbird, a mail client, must be able to display HTML in the
following cases:
- some email or news messages are in HTML
- most RSS and Open feeds are in HTML
- your Mail Start Page could be in HTML
In any of these cases, it displays the HTML (including any embedded
pictures) with the full power of Gecko, just like Firefox, and in fact,
using the same code. The only thing which it cannot do is follow links
from one HTML page to another.
Best regards,
Tony.
--
Hartley's Second Law:
Never sleep with anyone crazier than yourself.
Philip Chee
> On 03/06/11 14:59, ISHIKAWA, Chiaki wrote:
> [...]
>> Wny on earth does TB, a mail client, requires 3D acceleration (OpenGL)?
> [...]
>
> Thunderbird, a mail client, must be able to display HTML in the
> following cases:
>
> - some email or news messages are in HTML
> - most RSS and Open feeds are in HTML
> - your Mail Start Page could be in HTML
>
> In any of these cases, it displays the HTML (including any embedded
> pictures) with the full power of Gecko, just like Firefox, and in fact,
> using the same code. The only thing which it cannot do is follow links
> from one HTML page to another.
The functionality is there though, and if you install the Thunderbrowse
extension you can do that.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
ISHIKAWA, Chiaki
> On 03/06/11 14:59, ISHIKAWA, Chiaki wrote:
> [...]
>> Wny on earth does TB, a mail client, requires 3D acceleration (OpenGL)?
> [...]
>
> Thunderbird, a mail client, must be able to display HTML in the
> following cases:
>
> - some email or news messages are in HTML
> - most RSS and Open feeds are in HTML
> - your Mail Start Page could be in HTML
>
Thank you for your comment.
Right. I figured this out since someone sent me an HTML file with an
embedded JPEG file about a week ago.
I needed to save JPEG file to a local directory, and this action
followed a different code path in comm-central, and mozilla-central
where handling of saving something to a non-writable directory has been
a little lacking. This particular path of saving embedded JPEG file from
the HTML file handles the case of non-writable directory very gracefully
with proper error dialog. Very well, and then I had another motivation
to fix the bug by possibly comparing codes with this new found path.
Bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=567585
(This is basically a data loss. If you thought you saved an attachment
to a file and then delete the attachment, you will be sorry if the
saving actually failed silently.)
Well, I looked at the code paths. Unfortunately the new path didn't
offer much new information, and so I am still trying to improve my old
patch which I am going to submit again after merging it to the latest TB
trunk code. A kludge, but it works.
> In any of these cases, it displays the HTML (including any embedded
> pictures) with the full power of Gecko, just like Firefox, and in fact,
> using the same code. The only thing which it cannot do is follow links
> from one HTML page to another.
But rendering a content that requires OpenGL may be a little too much
for a mail client. That is my point. (Well, maybe a message rendering
pane can be a full browser, an external program. Maybe it is an extreme
position, but worth considering.)
"Using the same code" is one reason that saving attachment to a
non-writable directory is not handled very well or in somewhat confused
manner in TB trunk.
For example, nsHelperAppDlg.js that is invoked by left-clicking on an
attachment in TB uses "BROWSER" default download location.
(mozilla/toolkit/mozapps/downloads/nsHelperAppDlg.js)
whereas RIGHT-clicking on the attachment and save from the menu thereon
invokes a path that invokes a routine in .cpp and that path uses default
"MAILER" download location. (It is in nsMessenger.cpp code.
https://bugzilla.mozilla.org/show_bug.cgi?id=549719
Left clicking path fails silently to store attachments to a non-writable
directory. Right-clicking path shows terse error dialog TWICE now.
)
Messenger and browser default download location can have different
values in TB. If saving to a directory fails (say, due to
write-permission issue) using LEFT-clicking path, the mailer reverts to
a BROWSER default download location, which is very confusing. (Come to
think of it, I wonder whether the TB3's notion of BROWSER default
download location and FF's default location are related. They seem to be
saved under different DOT direcotries in Linux, at least.)
Now that I have read in some news articles that messenger(mailer)
development is going to be merged into browser development (?), better
integration may be coming. I am afraid that TB always had a backseat
from the viewpoint of developers' interest.
If I can offer an input the way integration goes,
I think mailer should not need OpenGL for operation.
There is a place for character only e-mail client even in the age of
smartphones with 1GHz CPU.
We can always invoke external application (Firefox) for rendering that
requires OpenGL and other advanced graphics operation if necessary.
By the way, instead of having a few different code paths, we may be able
to organize code by producing an object saving module (writing to a
file) as in
front-end for mail attachment ---> saving module
(nsHelperAppDlg.js, nsMessenger.cpp) to a local store
front-end for embedded data in HTML mail ---> ditto
(nsExternalHelperAppService.cpp ???)
front-end for objects fetched from remote
HTML server ---> ditto
Other front ends for objects to be saved ---> ditto
and we can concentrate the logic of file system permission handling,
save progress bar, etc. in this saving module if possible in ONE place
only(?)
But I am not that familiar with TB/FF code base to do this kind of
surgery. All I can do is to fix the broken nsHelperAppDlg.js for now.
Hmm. 30784 is also related to the bug I was mentioning???
(That bug is more than 10 years old ?!)
TIA
> Best regards,
> Tony.
Mark Banner
On 04/06/2011 04:24, ISHIKAWA, Chiaki wrote:
> (2011/06/04 3:35), Tony Mechelynck wrote:
>> In any of these cases, it displays the HTML (including any embedded
>> pictures) with the full power of Gecko, just like Firefox, and in fact,
>> using the same code. The only thing which it cannot do is follow links
>> from one HTML page to another.
>
> But rendering a content that requires OpenGL may be a little too much
> for a mail client. That is my point. (Well, maybe a message rendering
> pane can be a full browser, an external program. Maybe it is an extreme
> position, but worth considering.)
As we share much code with Firefox sometimes it is easier to be as close
as possible - including back ends such as OpenGL. This also gives us
several advantages - we don't get build bustage so frequently, we know
that the underlying architecture should work correctly (because it does
in the same configuration for Firefox) and lastly it also gives
extensions chance to experiment - extensions can display web pages, or
other content in Thunderbird, so seeing as this is the same core we're
basing on - we get a lot for free.
> "Using the same code" is one reason that saving attachment to a
> non-writable directory is not handled very well or in somewhat confused
> manner in TB trunk.
Whilst this could be caused by sharing code, it is somewhat different to
talking about sharing OpenGL. I suspect that it would be possible to
change the default locations if we felt we needed to (I've not looked in
detail into it).
> Now that I have read in some news articles that messenger(mailer)
> development is going to be merged into browser development (?), better
> integration may be coming. I am afraid that TB always had a backseat
> from the viewpoint of developers' interest.
No merging of development is happening. We're syncing Thunderbird
development cycles with Firefox, and we've merged two companies into
one, but the two teams are still separate.
> We can always invoke external application (Firefox) for rendering that
> requires OpenGL and other advanced graphics operation if necessary.
Except, that would degrade the user experience - why should they have to
switch to a different application to view something? We know from
experience that that sort of context switching isn't good.
Standard8
Joshua Cranmer
Even were Thunderbird were to do that, it probably wouldn't save much,
since we would still build Gecko with all of those pieces enabled. The
Gecko developers have become increasingly resistant to being able to
disable features in Gecko, and existing build configurations that
disable those features are quite liable to break. Given recent events,
even tracking the build configuration on Thunderbird's tinderbox would
be no guarantee of continued functionality.
Tony Mechelynck
[...]
> But rendering a content that requires OpenGL may be a little too much
> for a mail client. That is my point. (Well, maybe a message rendering
> pane can be a full browser, an external program. Maybe it is an extreme
> position, but worth considering.)
Not only a mail client, but also, among others, an RSS feed reader: this
is _my_ point. The way I see it, RSS feeds do use full HTML power; in
fact, AFAICT they're indistinguishable from web pages which are
delivered to you at a certain periodicity.
As for rendering anything HTML, even HTML mail, in an external browser,
I agree with the already given reply that it would degrade user
experience too much; I'd add that if you want to forbid any RSS feeds in
the mailer for anyone (except maybe via an external browser), that's the
end of Thunderbird feed reading: please don't do that. In SeaMonkey
(which of course is both a mailer and a browser so the perspective is
different) I have the choice of subscribing to feeds with the browser or
with the mailer (well, the "News and Blogs" section of the 3-pane
window) and I prefer the mailer.
Best regards,
Tony.
--
There was a bluestocking in Florence
Wrote anti-sex pamphlets in torrents,
Till a Spanish grandee,
Got her off with his knee,
And she burned all her works with abhorrence.
ISHIKAWA, Chiaki
> On 04/06/11 05:24, ISHIKAWA, Chiaki wrote:
> [...]
>> But rendering a content that requires OpenGL may be a little too much
>> for a mail client. That is my point. (Well, maybe a message rendering
>> pane can be a full browser, an external program. Maybe it is an extreme
>> position, but worth considering.)
> [...]
>
> Not only a mail client, but also, among others, an RSS feed reader: this
> is _my_ point. The way I see it, RSS feeds do use full HTML power; in
> fact, AFAICT they're indistinguishable from web pages which are
> delivered to you at a certain periodicity.
>
> As for rendering anything HTML, even HTML mail, in an external browser,
> I agree with the already given reply that it would degrade user
> experience too much; I'd add that if you want to forbid any RSS feeds in
> the mailer for anyone (except maybe via an external browser), that's the
> end of Thunderbird feed reading: please don't do that. In SeaMonkey
> (which of course is both a mailer and a browser so the perspective is
> different) I have the choice of subscribing to feeds with the browser or
> with the mailer (well, the "News and Blogs" section of the 3-pane
> window) and I prefer the mailer.
>
Maybe I should consider the users of mail client to access GMAIL account
as well as other simple POP3/IMAP servers. In that case, I agree that
having an HTML-understanding browser-like feature
is essential.
Seems that the user landscape has changed quite a lot, and
1GHz CPU on a mobile phone is a sign that character-only mailers may be
of the years past...
Emacs nowadays can show PNG/JPEG file inside its own buffer, and even
render PDF within its window. So this is the glimpse of things to come
(or already has come on many users portable devices).
Thank you for people's thought anyway.
I am back to fixing the bug which affects me everyday :-(
>
> Best regards,
> Tony.
Justin Dolske
> Wny on earth does TB, a mail client, requires 3D acceleration (OpenGL)?
In addition to what others wrote, OpenGL will be used to accelerate
rendering (at some point, I'm not sure this is enabled on Linux yet).
Justin
Tony Mechelynck
IIUC, on Linux only very few graphics drivers can yet be used without
crashing when OpenGL is enabled, and even so, it seems that some
enabling is being done by mistake (see e.g. crash bug 659842).
Best regards,
Tony.
--
"I bet the human brain is a kludge."
-- Marvin Minsky
Robert Kaiser
> IIUC, on Linux only very few graphics drivers can yet be used without
> crashing when OpenGL is enabled, and even so, it seems that some
> enabling is being done by mistake (see e.g. crash bug 659842).
Not really true in this extent. There are a numbers of buggy drivers
around and a number of buggy libraries, but AFAIK it's not really as bad
as you describe it here. (And the good thing with the open source
drivers is that they can be improved in reaction to our findings, I
don't really care about the closed drivers, though...)
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
Tony Mechelynck
> Tony Mechelynck schrieb:
>> IIUC, on Linux only very few graphics drivers can yet be used without
>> crashing when OpenGL is enabled, and even so, it seems that some
>> enabling is being done by mistake (see e.g. crash bug 659842).
>
> Not really true in this extent. There are a numbers of buggy drivers
> around and a number of buggy libraries, but AFAIK it's not really as bad
> as you describe it here. (And the good thing with the open source
> drivers is that they can be improved in reaction to our findings, I
> don't really care about the closed drivers, though...)
>
> Robert Kaiser
>
>
Well, I only have to go by what I read in the docs (Mozillazine KB,
MozillaWiki, etc.) and of course by the time a doc gets written it is
already obsolete by at least an hour, more often a day. I have heard say
that one of the best Linux drivers is for nvidia cards (my card is
Intel), and I've been having a repeatable crash at every shutdown, and
sometimes when reloading about:support, which has been moved by "the
people in the know" to some Bugzilla product about graphics, but
actually that's about the extent of my knowledge. I try to share it in
order to contribute to the general level of enlightenment, but of course
every time some information is passed around it degrades a little,
acquiring random noise...
Best regards,
Tony.
--
Angels we have heard on High
Tell us to go out and Buy.
-- Tom Lehrer
Robert Kaiser
> (my card is
> Intel), and I've been having a repeatable crash at every shutdown
I have two Intel-powered machines, one 4-year-old laptop (GM45) and one
brand-new desktop (SandyBridge), both running on Linux (openSUSE 11.4 or
Factory) and I haven't seen shutdown crashes with current builds, not
even when I tested WebGL support...
Benoit Jacob
> Tony Mechelynck schrieb:
>>
>> (my card is
>> Intel), and I've been having a repeatable crash at every shutdown
>
> I have two Intel-powered machines, one 4-year-old laptop (GM45) and one
> brand-new desktop (SandyBridge), both running on Linux (openSUSE 11.4 or
> Factory) and I haven't seen shutdown crashes with current builds, not even
> when I tested WebGL support...
Anyone who can still reproduce this, please go to
https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c51
and follow the instructions in comment 50 and reply to this bug. I
need to get logs from this build to understand what's happening here.
Benoit
>
> Robert Kaiser
>
>
> --
> Note that any statements of mine - no matter how passionate - are never
> meant to be offensive but very often as food for thought or possible
> arguments that we as a community should think about. And most of the time, I
> even appreciate irony and fun! :)
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>