Closed Bug 80812 Opened 23 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: Build Config, defect, P3)

Sun
Solaris

Tracking

(Not tracked)

VERIFIED INVALID
mozilla1.1alpha

People

(Reporter: timeless, Assigned: cls)

References

Details

Attachments

(1 file)

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)
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.
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
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".
Blocks: 79119
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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.
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.
Attached file results of CC -dryrun
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).
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 ?
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... ;-(
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.
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 !!)...
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.

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.
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...
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.
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... =:-)

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 .
Uhm... dumb question: Is it possible that this is a "gmake" issue (I am using 
Gmake 3.76.1) ?
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.

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.

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.
Severity: blocker → critical
Target Milestone: mozilla0.9.3 → mozilla1.0
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.
Severity: critical → major
Priority: P2 → P3
Target Milestone: mozilla1.0 → mozilla1.1
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
verified invalid.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: