[Pkg-mozext-maintainers] icedove-dev vs xulrunner-1.9.1-dev

[Mike Hommey]

On Tue, Apr 20, 2010 at 12:45:56PM -0400, Daniel Kahn Gillmor wrote:
> for those just getting looped in, this discussion is archived in the
> thread starting at:
> 
>  http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/2010-April/000487.html
> 
> On 04/13/2010 03:46 AM, Mike Hommey wrote:
> > On Mon, Apr 12, 2010 at 06:13:38PM -0400, Daniel Kahn Gillmor wrote:
> >> possibly even more worrisome, some of the include files seem to
> >> differ slightly, even in the directories labeled "stable", e.g.
> >> HAVE_CPP_2BYTE_WCHAR_T is defined in icedove/stable/xpcom-config.h,
> > 
> > This should definitely be changed. I'm on my way for a better "fix" on
> > xulrunner that I hope will be applied to icedove. I'll come back later
> > with that.
> 
> http://bugs.debian.org/577886 looks like another concern related to wide
> character types, as is (maybe) this bug related to firegpg in ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/firegpg/+bug/515872
> 
> Can you describe your plan (or point to docs about it)?  What do we need
> to do to get it applied to icedove as well?

Previously, xulrunner was built without -fshort-wchar. Building with has
several different problems, one being that it's not possible to mix
libraries built with -fshort-wchar and others built without (which iirc
happened), and another one being that it's not possible to use
-fshort-wchar on ARM at all.

What -fshort-wchar allows, on mozilla, is to be able to have literal
strings in utf-16 directly. Without -fshort-wchar, literal strings are
actually converted from ascii at runtime.

But that without considering HAVE_CPP_2BYTE_WCHAR_T.
HAVE_CPP_2BYTE_WCHAR_T is set when xulrunner has been built with
-fshort-wchar, and that ends up in xpcom-config.h.
In turn, in nsLiteralString.h and nsStringAPI.h, the definitions for
literal strings that use constructs that only work with -fshort-wchar
are #ifdef'ed with HAVE_CPP_2BYTE_WCHAR_T. Which means that building
against a SDK that was built with -fshort-wchar needs the -fshort-wchar
flag.

This particular issue was fixed a long time ago, and is probably the
root of the problem with firegpg on ubuntu: either -fshort-wchar doesn't
end up in the .pc file in the -dev package or firegpg doesn't take the
cflags value from the .pc file.

Anyways, in the mozilla 1.9.2 branch, there is a new way to get literal
strings in utf-16 without -fshort-wchar, which is to use new C++0x
constructs. These, in turn, require the -std=gnu++0x option. But I don't
feel this option needs to be in the .pc file.

Again, the build time choice is set in stone in xpcom-config.h.

The latest xulrunner version in unstable has has a backport of this new
check in configure, plus some c++0x fixes, and a diversion from upstream
which is the cause of bug #577886: It allows to properly use whatever
options has been set on gcc command line despite what is set in
xpcom-config.h, but warns when there is a difference. It also warns when
the runtime conversion is used instead of really literal strings.
#577886 is due to mozvoikko being built with -Werror, and turning the
warning into an error.

While the former warnings may be removed, or moved at another location
(it is currently in nscore.h but actually a lot of things are including
nscore.h that don't need the string literals, so in the end it probably
wasn't the right location), the latter will remain.
Please note that it doesn't really make a difference if you build with
-fshort-wchar when xulrunner was built with -std=gnu++0x and vice-versa,
but IMHO, -fshort-wchar should be avoided for the reasons given above.

I got Lucas to send me the build logs from all the build-rdeps from
xulrunner built against the latest version, which allows me to verify
some of them are definitely not doing the right thing (such as galeon
and kazehakase which are doing their own -fshort-wchar check instead of
taking what is in the .pc file). I overlooked the fact that it actually
broke mozvoikko, but dealing with these warnings is definitely in my
TODO-list.

FWIW, the relevant upstream (mozilla) bugs are:
https://bugzilla.mozilla.org/show_bug.cgi?id=559278
https://bugzilla.mozilla.org/show_bug.cgi?id=502301
https://bugzilla.mozilla.org/show_bug.cgi?id=502298

Mike