Closed Bug 80812 Opened 23 years ago Closed 22 years ago
CC: -D option without arguments
. Command Line too long
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".
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.
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.