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

[Mike Hommey]

On Tue, Apr 20, 2010 at 02:43:57PM -0400, Daniel Kahn Gillmor wrote:
> On 04/20/2010 01:24 PM, Mike Hommey wrote:
> > 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.
> 
> 
> hrm.  firegpg does use the pkg-config, but i don't see any mention of
> -fshort-wchar (or any other cflags options):
> 
> 0 dkg at pip:~$ pkg-config --cflags libxul
> -I/usr/include/xulrunner-1.9.1/stable -I/usr/include/nspr
> 0 dkg at pip:~$ pkg-config --cflags libxul-unstable
> -I/usr/include/xulrunner-1.9.1/unstable -I/usr/include/nspr
> 0 dkg at pip:~$
> 
> I've got xulrunner-dev 1.9.1.9-6 installed on i386.

You need to check xulrunner-dev (or whatever firegpg uses on ubuntu)
from ubuntu.

> > 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.
> 
> iiuc, this means that a change in any C++ source is needed to use the
> correct constructs, as well as the -std=gnu++0x flag, right?

Only the flags need to be changed. The C++ source is supposed to be
using macros which meaning depends on HAVE_CPP_2BYTE_WCHAR_T and
HAVE_CPP_CHAR16_T.

> > Again, the build time choice is set in stone in xpcom-config.h.
> 
> so as long as the packages -include xpcom-config.h, they should not need
> to set -fshort-wchar explicitly?  Or are you saying they should supply
> -fshort-wchar based on the contents of xpcom-config.h ?

With current upstream, they should supply -fshort-wchar based on the
contents of the .pc file, or based on the contents of xpcom-config.h.
With current version in debian, they can use whatever they want,
but will get a warning if that doesn't match what xulrunner was built
with or if it results in using the runtime conversions.

> > 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.
> 
> Do these fixes need to propagate into icedove and iceape as well, then,
> given that they embed xulrunner?  Should i file bugs against those packages?

Yes, they should, but I was waiting to already settle on how things are
going to be in xulrunner before going forward with the other ones.

Mike