basd on Bugzilla Bug 100873 JS Hard Codes JS_HAVE_LONG_LONG to the detriment of FreeBSD. timeless@sorefbsd:~/mozilla/obj-gtk-i386-unknown-freebsd4.4/js/src/xpconnect/to ols/src: makensXPCToolsCompiler.cpp c++ -o nsXPCToolsCompiler.o -c -DOSTYPE=\"FreeBSD4\" -DOSARCH=\"FreeBSD\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI -DJSFILE -DJS_THREADSAFE -I../../../../../dist/include -I../../../../../dist/include -I/home/timeless/mozilla/obj-gtk-i386-unknown-freebsd4.4/dist/include/nspr -I/usr/X11R6/include -fPIC -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual -Wsynth -pedantic -Wno-long-long -pipe -pthread -DDEBUG -DDEBUG_timeless -DTRACING -g -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../../../config-defs.h -Wp,-MD,.deps/nsXPCToolsCompiler.pp /home/timeless/mozilla/js/src/xpconnect/tools/src/nsXPCToolsCompiler.cpp In file included from /home/timeless/mozilla/js/src/xpconnect/tools/src/nsXPCToolsCompiler.cpp:38: /home/timeless/mozilla/js/src/xpconnect/tools/src/xpctools_private.h:126: macro `JSLL_NEG' used with too many (3) args /home/timeless/mozilla/js/src/xpconnect/tools/src/xpctools_private.h:124: end of file read inside definition /home/timeless/mozilla/js/src/xpconnect/tools/src/nsXPCToolsCompiler.cpp:159: syntax error at end of input gmake: *** [nsXPCToolsCompiler.o] Error 1 This is more of a correctness issue for the moment, because as we run into OS's that don't build we're just throwing the JS_HAVE_LONG_LONG switch... <q class="ot"> at some point i'll probably ask about autoconf or something so i don't need to keep adding *BSD entries</q>
Time to autoconfig this macro? /be
Assignee: rogerl → khanson
well, this is funny. 18months to the day. anyway, i was looking at this yesterday and i figured out the problem. dbradley and i had talked about it a few months back when i was fixing JSNow for y2038 and it failed to build on one of my compilers (openwatcom or digitalmars), the problem is that *LL_INIT() may only be used as an initializer. dbradley mentioned that there was an instance in xpconnect which would probably cause a problem, it turns out that it was this instance. the fix is easy, i've tested it on msvc6 w32 with and without HAVE_LONG_LONG, it compiles. (but i didn't build a full tree so it didn't link) for people interested in testing w/o have_long_long you'll need to twiddle dist/include/nspr/prcpucfg.h
Assignee: khanson → timeless
OS: other → FreeBSD
Summary: !JS_HAVE_LONG_LONG fallback doesn't work @ nsXPCToolsCompiler.cpp > xpctools_private.h > jslong.h → nsXPCToolsCompiler.cpp > xpctools_private.h incorrectly uses LL_INIT which breaks for !*HAVE_LONG_LONG
Target Milestone: Future → ---
Created attachment 118186 [details] [diff] [review] use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp
Comment on attachment 118186 [details] [diff] [review] use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp r=dbradley You can remove the jslong.h include
Attachment #118186 - Flags: review?(dbradley) → review+
timeless: do we still need to support any compiler that doesn't have long long or an equivalent 64-bit integer type?
Comment on attachment 118186 [details] [diff] [review] use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp we intend to support embedding platforms which will have that restriction
Attachment #118186 - Flags: superreview?(dmose)
Comment on attachment 118186 [details] [diff] [review] use LL_INIT correctly so that platforms without HAVE_LONG_LONG don't carp firstname.lastname@example.org
Attachment #118186 - Flags: superreview?(dmose) → superreview+
checked in (and jslong.h removed per dbradley since it is no longer used).
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
It is important for me to know that there really are compilers that don't have long long (or a 64-bit integer type) that we need to support. Recently I have started to tell people that it is no longer necessary to use NSPR's LL_ macros when writing new code. The reasons are: 1. HAVE_LONG_LONG is defined for all the compilers that NSPR currently supports. (See the mozilla/nsprpub/pr/include/md/*.cfg files.) 2. The 1999 revision of the C Standard (also known as C99) added the long long int type. I expect that long long will be universally supported by compilers very soon. Could Brendan or mozilla.org's language and porting exports decide whether there is a need to support compilers that don't have long long or a 64-bit integer type? My recommendation is that it is not necessary, but I'd like to hear your expert opinions.
Checkin verified; including removal of #include "jslong.h"
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.