On Fri, 2008-06-13 at 07:17 +0200, Mike Hommey wrote: > On Fri, Jun 13, 2008 at 02:00:00AM +0100, Ben Hutchings wrote: > > On Thu, 2008-06-12 at 17:22 +0300, Riku Voipio wrote: > > > > The xulrunner 1.9 headers now use wchar_t but still require it to be > > > > defined as a 16-bit type. The pkg-config files specify -fshort-wchar > > > > to ensure that this is the case. > > > > > > duplicate of #485618 ? > > > > Not exactly - you think -fshort-wchar should not be used on armel; I > > think it should not be used anywhere. > > > > > > Now, the question is, why does it suddenly break? > > > > > > It appears to be introduced by gcc-4.3, gcc-4.2 appeared to be more > > > liberal with mixing -short-wchar and -long-wchar code. > > > > XULRunner 1.8 didn't specify -fshort-wchar in pkg-config files, that I > > noticed. > > But it built with it being set, and according to buildd logs, videolink > doesn't use the -fshort-wchar from pkg-config files even if it is there.
That's because I added a workaround after seeing this. Look at <http://buildd.debian.org/build.cgi?pkg=videolink;ver=1.2.4-1>. > Apart the armel issue, could you give more details about what is > happening ? Changing the size of wchar_t prevents applications that use libxul from using other libraries which use wchar_t in their API. This is a Bad Thing. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings.
signature.asc
Description: This is a digitally signed message part
