530982 - nsILocalFile.idl:100: Error: unsigned const declaration 'DELETE_ON_CLOSE' initialized with negative constant

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Nicholas Nethercote [inactive]]

I'm trying to build a 32-bit Firefox on a 64-bit Ubuntu 9.04 Linux box.  My .mozconfig:

mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=browser
export PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig
CC="gcc -m32"
CXX="g++ -m32"
AR=ar
ac_add_options --x-libraries=/usr/lib32
ac_add_options --target=i686-pc-linux
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/debug32
ac_add_options --enable-debug
#ac_add_options --enable-valgrind

I build with:

  MOZCONFIG=/home/njn/.mozconfig-debug32 make -f client.mk

and get this error:

/home/njn/moz/ws0/debug32/dist/bin/xpidl -m header -w -I/home/njn/moz/ws0/xpcom/io -I../../dist/idl -o _xpidlgen/nsILocalFile /home/njn/moz/ws0/xpcom/io/nsILocalFile.idl
/home/njn/moz/ws0/xpcom/io/nsILocalFile.idl:100: Error: unsigned const declaration 'DELETE_ON_CLOSE' initialized with negative constant

dvander got the same error when he tried on his Ubuntu 9.10 box.

Comment 1

[Nicholas Nethercote [inactive]]

This is with:

  gcc (Ubuntu 43.3-5ubuntu4) 4.3.3

Comment 2

[Benjamin Smedberg]

This error is coming from libIDL, not the compiler... I suspect an upgraded version of libIDL is to blame. I don't know if there's a workaround that would maintain binary compatibility, or whether somebody should try to fix bug 458936 and ditch libIDL completely.

Comment 3

[Nicholas Nethercote [inactive]]

(In reply to comment #2)
> This error is coming from libIDL, not the compiler... I suspect an upgraded
> version of libIDL is to blame.

You mean the version of libIDL on my Ubuntu box is to blame?  'libIDL-config-2 --version" tells me "0.8.13", I don't know if that's relevant but it's the only libIDL thing I could find.

Is the compile error incorrect?  The relevant line is:

    const unsigned long DELETE_ON_CLOSE = 0x80000000;

The error makes some kind of sense to me... if 0x80000000 is interpreted as a signed 32-bit int and ends up as -1, which then causes the error when it's assigned to the unsigned long.  But I don't know the first thing about IDL.

I'm surprised this hasn't come up before.  Is doing a 32-bit build on Ubuntu X64 such an uncommon thing?

I tried changing the variable to a 'long', and then another similar one that caused problems immediately afterwards.  But then I got some ridiculous values in $OBJDIR/dist/include/nsISupportsPrimitives.h:

class NS_NO_VTABLE NS_SCRIPTABLE nsISupportsPrimitive : public nsISupports {
 public:

  NS_DECLARE_STATIC_IID_ACCESSOR(NS_ISUPPORTSPRIMITIVE_IID)

  enum { TYPE_ID = 18446744069414584321U };

  enum { TYPE_CSTRING = 18446744069414584322U };

  ...
}

Those bogusly large numbers are very close to (2^64 - 2^32), so there's some type weirdness/overflow going on.

Comment 4

[Benjamin Smedberg]

This only appears on 32-bit builds? I'm surprised, because I'd expect us to still be using a 64-bit build toolchain... is CROSS_COMPILE set in your mozconfig? I'm using libidl 0.8.10 on Fedora for 64->32 cross without incident.

Comment 5

[Nicholas Nethercote [inactive]]

Yes, it's only 32-bit builds;  64-bit builds work fine.

CROSS_COMPILE is not set.  My mozconfig is shown in comment 0.  I set it up by trying to follow https://developer.mozilla.org/en/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS, although the instructions for Ubuntu were a bit unclear.

It's possible that I need a 32-bit install of libIDL and don't have one.  I have the libidl0 and libidl-dev packages installed.  My /usr/lib/libIDL-2.so is 64-bit, but my /usr/lib32/libIDL-2.so is 32-bit.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #5)
> CROSS_COMPILE is not set.  My mozconfig is shown in comment 0.  I set it up by
> trying to follow
> https://developer.mozilla.org/en/Compiling_32-bit_Firefox_on_a_Linux_64-bit_OS,
> although the instructions for Ubuntu were a bit unclear.

Yep, I just hit the same thing trying to do a 32-bit build on Ubuntu 9.10, following the same instructions (although I had an old copy of the necessary mozconfig, without the AR=ar line).

Comment 7

[[e-mail]]

I've seen this bug because sscanf on SFU is broken and won't scan %llu.

Comment 8

[(not currently active) Ted Mielczarek]

I hit this same bug, and forcing a host xpidl to be built works around it. I just added:
export CROSS_COMPILE=1
to my mozconfig. bsmedberg's suspicion in comment 2 (that this is a bug in Ubuntu's 32-bit libIDL) sounds likely to me.

Comment 9

[Nicholas Nethercote [inactive]]

FWIW, I upgraded to Ubuntu 9.10 and am not hitting this problem any more.  (I'm now hitting a Cairo compile error...)

Comment 10

[Nicholas Nethercote [inactive]]

No longer a problem for me.