80812 - CC: -D option without arguments. Command Line too long

Status: VERIFIED INVALID

(SeaMonkey :: Build Config, defect, P3)

Description

[timeless]

I'm building xlib w/ Forte5 on solaris.
[.mozconfig]
ac_add_options --without-gtk
ac_add_options --with-xlib
ac_add_options --enable-toolkit=xlib
ac_add_options --enable-ultrasparc
ac_add_options --enable-optimize
ac_add_options --disable-tests
ac_add_options --with-libIDL-prefix=/tmp/idl/
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj-@CONFIG_GUESS@
[env]
setenv CC cc
setenv CCC CC
[~/sun4bin/whoami]
#!/bin/sh
echo timeless
---- solaris7sparc. My username is 5 chars long (i just added the whoami hack 
yesterday), and I usually build w/ gcc ----
CC -o nsInternetCiter.o -c -DENABLE_EDITOR_API_LOG=1 -DOSTYPE=\"SunOS5\" 
-DOSARCH=\"SunOS\" -DMOZ_RE
FLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI   -I../../dist/include 
-I../../dist/include -I/tmp/obj-sparc-s
un-solaris2.7/dist/include/nspr      -I/usr/local/X11R6.3/include   -KPIC  
-I/usr/local/X11R6.3/incl
ude -mt -O  -DDEBUG -DDEBUG_timeless -DTRACING -g -I/usr/local/X11R6.3/include 
-DMOZILLA_CLIENT -DBR
OKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino 
-DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOT
E=1 -DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 
-DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1
 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 
-DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1
 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_SYS_FILIO_H=1 -DHAVE_NL_TYPES_H
=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 
-DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=
1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 
-DHAVE_RANDOM=1 -DHAVE_QSORT=1
 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 
-DHAVE_LOCALTIME_R=1 -DHAVE_STA
TVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=1 -DHAVE_RINT=1 -DHAVE_NL_LANGINFO=1 
-DHAVE_GETTIMEOFDAY=1 -DG
ETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_OSTREAM=1 
-DHAVE_CPP_EXPLICIT=1
-DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 
-DHAVE_CPP_ACCESS_CHANGIN
G_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 
-DHAVE_CPP_UNAMBIGUOUS_S
TD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 
-DNEED_CPP_UNUSED_IMPLEME
NTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 -DMOZ_MAIL_NEWS=1 
-DMOZ_EDITOR_API_LOG=1 -DMOZ_
ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 
-DNSCAP_DONT_PROVIDE_NONCONST_OPEQ=1 -DULTRA_SPARC=1 -D
DETECT_WEBSHELL_LEAKS=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 
-DMOZ_XSL=1 -DMOZ_NE
W_CACHE=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 
-DHAVE_MOVEMAIL=1 -DJ
S_THREADSAFE=1  /tmp/mozilla/editor/base/nsInternetCiter.cpp
CC: -D option without arguments

For editor, we don't need to pass in the MAIL related switches

This commandline worked:
CC -o nsInternetCiter.o -c -DENABLE_EDITOR_API_LOG=1 -DOSTYPE=\"SunOS5\" 
-DOSARCH=\"SunOS\" -DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI   
-I../../dist/include -I../../dist/include 
-I/tmp/obj-sparc-sun-solaris2.7/dist/include/nspr      
-I/usr/local/X11R6.3/include   -KPIC  -I/usr/local/X11R6.3/include -mt -O  
-DDEBUG -DDEBUG_timeless -DTRACING -g -I/usr/local/X11R6.3/include 
-DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 
-DD_INO=d_ino -DMOZ_WIDGET_XLIB=1 -DMOZ_ENABLE_XREMOTE=1 
-DMOZ_DEFAULT_TOOLKIT=\"xlib\" -DMOZ_X11=1 -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1 
-DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 
-DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_FILIO_H=1 -DHAVE_NL_TYPES_H=1 
-DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1 
-DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBSOCKET=1 
-DHAVE_LIBPOSIX4=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 
-DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 
-DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=1 -DHAVE_RINT=1 
-DHAVE_NL_LANGINFO=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 
-DHAVE_IOS_BINARY=1 -DHAVE_OSTREAM=1 -DHAVE_CPP_EXPLICIT=1 
-DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_TEMPLATE_SYNTAX=1 
-DHAVE_CPP_ACCESS_CHANGING_USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 
-DHAVE_CPP_NAMESPACE_STD=1 -DHAVE_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 
-DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_TO_VOID_PTR=1 
-DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMOZ_LOGGING=1 
-DMOZ_EDITOR_API_LOG=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DIBMBIDI=1 
-DNSCAP_DONT_PROVIDE_NONCONST_OPEQ=1 -DULTRA_SPARC=1 -DDETECT_WEBSHELL_LEAKS=1 
-DMOZ_USER_DIR=\".mozilla\" -DMOZ_XUL=1 -DINCLUDE_XUL=1 -DMOZ_XSL=1 
-DMOZ_NEW_CACHE=1 -DUSE_IMG2=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 
-DJS_THREADSAFE=1  /tmp/mozilla/editor/base/nsInternetCiter.cpp

I hope to try to set up an xlib tinderbox that does both gcc and forte 
(probably one in the morning and one afternoon)

Comment 1

[cls]

So, we've hit this problem multiple times in the past (and periodically whenever
nebiros does a dep build).  We always assumed that it was a compiler error
because it would go away if we set each of the defines to have =1.  The posix
cmdline limit is 4k chars but I vaguely remember someone saying that solaris'
/bin/sh has a limit of 2k.  If so, then we're in major trouble and we need to
seriously rethink the strategy of a) making all toplevel defines global to the
project and b) only putting the files in an include file for gcc.

Comment 2

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

The -D without any arguments wasn't the error message that convinced me that
nebiros needed to be a clobber build.  It was errors resulting from
doubly-quoted strings.  I only remember that error message when someone added a
"-DXXX" to a makefile instead of a "-DXXX=1".

Comment 3

[cls]

I upgraded both my local machine & nebiros with the SunSolve recommended patches
for Solaris 7 plus the latest versions of the patches we require from
http://www.mozilla.org/unix/solaris-build.html but to no avail.  I'm still
hitting that silly error on both machines.  I'm in the middle of testing a huge
but simple patch that adds =1 to each bare define in the Makefiles.  If it
"fixes" the problem, then we should be able to say that it's just a compiler
bug.  If it doesn't, then we'll have to revisit commandline length issue.

Comment 4

[cls]

Well, the mondo patch failed.  Same error in string/src/ .  I'm not totally
convinced that it's a commandline issue either as using bash, ksh or
/usr/xpg4/bin/sh instead of /bin/sh also causes the build to fail on the same file.

Comment 5

[cls]

Attachment: results of CC -dryrun

Comment 6

[cls]

Oops, the attached file didn't linewrap like I was expecting. The interesting
part is in ccfe call:

/opt/SUNWspro/SC5.0/bin/ccfe -I../../dist/include <...>
/opt/SUNWspro/SC5.0/bin/CC -ptk "-dryrun -c -DOSTYPE= <...> -DUNIX_ASYNC_DNS='1'
-D" -D_REENTRANT ....

So at least we know where the empty -D is coming from.  Next question would be
why is WS cutting off the input that's passed to the -ptk option when it clearly
can see the entire input (which follows at the end of that same line).

Comment 7

[Roland Mainz]

I do not have this problem with Sun Workshop 6 Update 2 EA2 and
$PATH=/usr/java/bin:/usr/local/bin:/usr/dt/bin:/usr/openwin/bin:/usr/xpg4/bin:/usr/lib/nis:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/ucb

mhhh... timeless, wanna try it with putting /usr/xpg4/bin before
/usr/sbin:/usr/bin:/usr/ccs/bin ?

Comment 8

[Roland Mainz]

cls:
Did you really apply the whole current "recommended patch cluster" ? 
If yes - then bug 85550 can be marked as "FIXED"... :-)

BTW: "nebiros" is still missing the MU4(=maintaince update 4) patch package,
too... ;-(

Comment 9

[cls]

Roland:
I installed the 44 meg patch cluster from
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access for solaris
7.    Whatever was current as of Sunday afternoon.  Does the MU4 patch fix this
problem?  If not, then I'm not going to worry about it at this time.

Comment 10

[Roland Mainz]

cls:
I do not have this problem on my machine. Two differences from "nebiros":
- I am using a fully patched machine - MU4, recommended patches, some non-public
patches
- I am using Sun Workshop 6 "Update _2EA2_" - ("nebiros" uses "Update
1+patches")

Both items may cause this problem... ;-((

MU4 may fix it - or not. I do not have any clue - that "maintaince update"
patches nearly everything on that box (patch cluster is ~306MB !!)...

Comment 11

[cls]

Roland:
You are not using WorkShop 5.0.  Timeless is using 5.0, nebiros is using 5.0 and
my local solaris box is using 5.0.  While the problem may not exist in 6 U2EA2,
that does not help us in the least as the upgrade to 6.0 is not freely
available.  If it is, please provide that info and we can see about changing our
minimally supported compiler.  
MU4 appears to require a maintenance support contract from Sun (based upon the
link you provided in bug 85550).  Not everyone with a solaris box has that.  I'd
imagine the same applies to the "non-public" patches.   We need to find a better
solution.

Comment 12

[Jon Granrose]

antitux is our build team sysadmin now so he can apply any patches we need on
Netscape build systems.  I agree that we should try to fix any build problems
with publicly available patches, but worse comes to worse, last I checked I
still had access to the non-public Sun patches so I should be able to get any we
need if antitux doesn't have access.

Comment 13

[Roland Mainz]

cls:
Everyone can register himself/herself with the solregis(1) tool 
(/usr/dt/bin/solregis) - those username/password used for that are valid for  
http://access1.sun.com/Products/solaris/mu/data/S7_MU4/solaris7_MU4.html , too.

Or ping me if you have problems getting that *.zip thingie...

Comment 14

[timeless]

erm, i should note that i foolishly asked my system to upgrade, so it's now 
using forte6 update0 -- which means i upgraded to a broken build system. when 
you guys iron out exact directions that i can give to my admin (as a request) i 
might be able to get a few more builds done, no guarantees as my account will 
soon expire.

Comment 15

[Roland Mainz]

timeless:
- Sun Workshop 6 Update 1 + patches from
http://www.mozilla.org/unix/solaris-build.html
OR
- Sun Workshop 6 Update 2 EA2 (http://access1.sun.com/fortedevprod/) - that's
the same I am using here. No problems known (may require --disable-ldap - I am
killing this bug this week), no patches (except Solaris recommended ones)
required.

WS6U2EA2 is EarlyAccess... I know... but we are already using it here since a
long time and it works nearly perfectly (uhm... except new features like -xipo
etc. etc. which are not "ON" by default)... - at least better than U1 in 64bit
sparcv9 mode... =:-)

Comment 16

[cls]

Roland:
Thanks for the pointer.  I registered and installed the MU4 update on my local
box.  It didn't make a difference.  I'm still hitting the same error in
string/src .

Comment 17

[Roland Mainz]

Uhm... dumb question: Is it possible that this is a "gmake" issue (I am using 
Gmake 3.76.1) ?

Comment 18

[cls]

I'm using 3.76.1 as well.  It is not a gmake issue.  The attachment I made of
the -dryrun clearly shows the entire line being passed to CC as well as the
entire set of args being passed to *certain parts* of the compiler's driver.  
CC appears to have a 2018 char limit on whatever gets passed to ccfe -ptk .  If
you do a -dryrun on other source files, you may notice that the last variable
within the -ptk quotes is being cut off.

Comment 19

[cls]

Ok, forget what I said about the -ptk length limit.  I checked in a couple of
patches this week to remove extraneous defines from configure.in.  I also
applied the patch in bug 89793 on my local solaris box.  Now, it's chopping off
the -D at around 1800 or so chars.  I still haven't gotten a build working on
that box although nebiros has since gone green.  The build usually progresses up
to netwerk before it dies now.

Comment 20

[cls]

Bumping out to 1.0 and dropping severity to critical as the problem can be
worked around by modifying config/autoconf.mk and adding bogus defines to
DEFINES.  A very lame workaround but technically, this isn't a Mozilla bug.

Comment 21

[hacker formerly known as [e-mail]]

I still want to remove the defines from the command line for non-gcc builds but
we're not going to hold 1.0 for it.

Comment 22

[hacker formerly known as [e-mail]]

I haven't seen this issue in a long while so I'm guessing that the updates for
WS 6.2 finally fixed this issue.

Comment 23

[Jon Granrose]

verified invalid.