698264 - build fails because of undefined C++11 user-defined literals

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Octoploid]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20100101 Firefox/10.0a1
Build ID: 20111025215725

Steps to reproduce:

gcc-4.7.0 recently (2011-10-26) implemented the new C++11 user-defined literals.

It turns out that the mozilla source contains a few errors according
to the new standard:

c++ -o nsGlueLinkingDlopen.i_o -c -I../../../dist/system_wrappers -include
/var/tmp/mozilla-central/config/gcc_hidden.h -DOSTYPE=\"Linux3.1\"
-DOSARCH=Linux -DXPCOM_GLUE -DTARGET_XPCOM_ABI=\"x86_64-gcc3\"
-I/var/tmp/mozilla-central/xpcom/glue/standalone/../../build
-I/var/tmp/mozilla-central/xpcom/glue/standalone -I. -I../../../dist/include
-I../../../dist/include/nsprpub -I/usr/include/nspr -I/usr/include/nss -fPIC
-fno-rtti -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 -march=native
-ffunction-sections -fdata-sections -fvisibility-inlines-hidden -fpermissive
-Wno-delete-non-virtual-dtor -fno-exceptions -fno-strict-aliasing -std=gnu++0x
-pthread -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED
-fprofile-generate -O3 -fomit-frame-pointer -DMOZILLA_CLIENT -include
../../../mozilla-config.h -MD -MF .deps/nsGlueLinkingDlopen.pp
/var/tmp/mozilla-central/xpcom/glue/standalone/nsGlueLinkingDlopen.cpp

/var/tmp/mozilla-central/xpcom/glue/standalone/nsGlueLinkingDlopen.cpp: In
function ‘nsresult XPCOMGlueLoad(const char*, nsresult (**)(XPCOMFunctions*,
const char*))’:
/var/tmp/mozilla-central/xpcom/glue/standalone/nsGlueLinkingDlopen.cpp:231:68:
error: unable to find user-defined string literal operator ‘operator""
MOZ_DLL_SUFFIX’

This happened because ./xpcom/build/nsXPCOMPrivate.h contains:
#define XUL_DLL   "libxul"MOZ_DLL_SUFFIX
changing it to:
#define XUL_DLL   "libxul" MOZ_DLL_SUFFIX
fixes this error.


The other problem occurs in nss: 
 error: inconsistent user-defined literal suffixes ‘fips’ and
‘SECMOD_SLOT_FLAGS’ in string literal
 error: unable to find user-defined string literal operator
‘operator"" fips’

Replacing the following macro in secmodt.h:
#define SECMOD_MAKE_NSS_FLAGS(fips,slot) \
"Flags=internal,critical"fips" slotparams=("#slot"={"SECMOD_SLOT_FLAGS"})"
with:
#define SECMOD_MAKE_NSS_FLAGS(fips,slot) \                                      
"Flags=internal,critical" fips" slotparams=("#slot"={" SECMOD_SLOT_FLAGS"})"
fixes this second issue.

Comment 1

[(not currently active) Ted Mielczarek]

Can you submit these in patch form? (We might have to use a separate bug for NSS since it works as a separate project, in CVS.)

Comment 2

[Octoploid]

(In reply to Ted Mielczarek [:ted, :luser] from comment #1)
> Can you submit these in patch form? (We might have to use a separate bug for
> NSS since it works as a separate project, in CVS.)

Will do. But lets wait a few days, because I'm not really sure
if this is not an gcc implementation bug. (Macro substitution 
should happen before user-defined literals parsing IMO.)

See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50917

Comment 3

[Octoploid]

Attachment: nsXPCOMPrivate.h C++11 user-defined literals fix

OK. The experts have spoken:
https://groups.google.com/forum/#!topic/comp.std.c++/9nD4Mb8pN1Q

This patch fixes the issue in nsXPCOMPrivate.h.

Comment 4

[Benjamin Smedberg]

Comment on attachment 570800 [details] [diff] [review]
nsXPCOMPrivate.h C++11 user-defined literals fix

ugh

Comment 5

[Octoploid]

NSS bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=698592

Comment 6

[(not currently active) Ted Mielczarek]

Thanks for the patch (and for splitting off the NSS patch).

Comment 7

[Ed Morley [:emorley]]

Please could you tweak your hgrc to automatically add author info (guide here: http://blog.bonardo.net/2010/06/22/so-youre-about-to-use-checkin-needed) + add a commit message when attaching patches, since it makes pushing half a dozen checkin-neededs a lot easier. Thanks :-)

Comment 8

[Jacek Caban]

https://hg.mozilla.org/integration/mozilla-inbound/rev/611c44e8e3cd

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/611c44e8e3cd