User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030607 Mozilla Firebird/0.6 Build Identifier: We should run glib (in moz_tools/include) through dos2unix. To get rid of extraneous \r (carriage return) characters Reproducible: Always Steps to Reproduce:
The last sentence under the Software Installation heading on the build page, http://www.mozilla.org/build/win32.html#ss2.2, already says this.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
Actually I was asked to file this bug, by dmose. The idea is to have a correct dox2unix'ed file in CVS, so that we don't have to run dos2unix every time we use the file.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Those files don't come from the mozilla/ cvs tree. Someone would have to roll another wintools.zip (or equivalent) tarball to "fix" that issue.
*** Bug 209803 has been marked as a duplicate of this bug. ***
Actually the issue is that acconfig.h config.h glib.h and glibconfig.h have double CRs which is obviously wrong.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Taking... I've rolled a new wintools.zip. Neil: right, but glib.h and glibconfig.h are the only ones where it causes a problem, because they have line-spanning macros in them.
Assignee: mozbugs-build → dmose
New wintools.zip is at <http://redpuma.net/wintools.zip>. It should function exactly as the original does, as described at <http://www.mozilla.org/build/win32.html>. If I can get people to test this version with both a MinGW build and an MSVC build and it works both places, we can replace the existing file with this one.
Status: NEW → ASSIGNED
I was going to test this. But your modified zip has all the newlines (0x0a), from glib.h and glibconfig.h, stripped out and one carriage return (0x0d) per line left in. That can't be what you meant to do, is it? Brian
To clarify: acconfig.h config.h glib.h and glibconfig.h have duplicated carriage returns in their line endings, i.e. ^M^M^J while all the other files in wintools.zip have the Windows standard convention of ^M^J line endings. Incorrect Correct File Name 3,165 3,058 acconfig.h 3,753 3,615 config.h 95,704 92,918 glib.h 5,328 5,155 glibconfig.h
Summary: Remove carriage returns from glib → Remove duplicated carriage returns from glib
Indeed, my change was probably the wrong one. If you want to take this bug and run with it, feel free...
OK, here's a URL to my new wintools.zip - you'll notice it's somewhat smaller than the original one because I used zip -r9DX * and not beacuse of the stripping of the spurious carriage returns which were compressed away anyway.
This bug hasn't been touched in a while, but mento uploaded a new wintools.zip file for me since I've been building SM and it worked perfectly. I'm updating the URL with his build since Neil's seems to be dead and reassigning to him to finish this up.
http://jackassofalltrades.com/tmp/wintools.zip I built this by running "tr -s '\015'" on all text files in the archive, to turn repeated strings of ^M into a single ^M: ^M^M^J -> ^M^J. I came up with the new archive before I found this bug - not the first time we've duplicated each other's work, Neil! :) Sam's tested this but I'd appreciate it if a few others could give it a try as well before I foist it on the world. For reference, his error while building xpidl.c was: In file included from c:/moztools/include/glib.h:131, from c:/mozilla/source/mozilla/xpcom/typelib/xpidl/xpidl.h:49, from c:/mozilla/source/mozilla/xpcom/typelib/xpidl/xpidl.c:42: c:/moztools/include/glibconfig.h:245: error: syntax error before '?' token because gcc was (rightly, in my opinion) interpreting ^M^M^J as newline-newline, and the erroneous blank line didn't have a backslash to direct the compiler to ignore the newline. What was intended to be a continuation of a #define was not being preprocessed and instead was fed directly into the compiler.
(In reply to comment #13) >I came up with the new archive before I found this bug - not the first time >we've duplicated each other's work, Neil! :) So you've checked that your .zip duplicates mine? ;-) Note: my .zip was made unavailable for over two weeks because a utility company dug up the wrong cable by mistake :-( but you should have access now.
Actually, you missed a file :) buildtools/windows/source/make-3.79.1/dosbuild.bat I rolled a new version of wintools.zip, this time, removing all of the CVS directories and the empty buildtools/tar. This one is zip-compressed with p7zip, and directory entries have been removed from the zip file (a la zip -D). That little experiment saves about a hundred kB compared to the current file. So, unless there are any objections, let's get someone with access to copy this wintools.zip from the URL field to stage:mozilla/source. Chris Cooper, come on down!
Summary: Remove duplicated carriage returns from glib → Remove duplicated carriage returns from glib (wintools)
rolling a new wintools.zip with file modes included, stand by
There's a new wintools.zip at http://jackassofalltrades.com/tmp/wintools.zip with fixed newlines. File modes were changed for *.dll and *.exe so that cygwin unzip will unpack the files with the x-bit set. This is ready to go live.
Mark: if you are going to release a new wintools.zip, we should take the opportunity to remove obsolete files in it. This will be more work though. The entire "alpha" subdirectory under "bin" can be removed because we don't support Windows NT for Alpha. The gmake.exe, shmsdos.exe, and uname.exe executables can be removed. They are all replaced by Cygwin: shmsdos.exe is replaced by sh.exe, gmake.exe is replaced by make.exe, and uname.exe is replaced by the same-named uname.exe in Cygwin. Under "source", the subdirectories "make-3.79.1" and "uname" can be removed. The "shmsdos" subdirectory can be renamed "nsinstall", with the files shmsdos.c and shmsdos.mak removed and the README file updated. Finally, update "windows/bin/README" to reflect the removed files. Perhaps you could do this as a separate bug.
Wan-Teh, what is the bundled nsinstall.exe used for? I'd like to update the READMEs to accurately reflect the current purposes.
Mark: on most platforms, we build the nsinstall program from source code (there are multiple copies; one of them is mozilla/config/nsinstall.c). I don't remember why, but we didn't port nsinstall.c to Windows (and perhaps OS/2, too). Instead, we implemented nsinstall as a built-in command of the lightweight shell shmsdos.exe. Later, we supported using a real shell, such as MKS Korn shell, with standard GNU make, and provided nsinstall.exe as a standalone program. The source for nsinstall.exe is a subset of the source for shmsdos.exe. The long-term solution would be to either eliminate the use of nsinstall on all platforms or build nsinstall.c from source code on Windows.
Assignee: mark → nobody
Component: Build Config → MozillaBuild
Product: SeaMonkey → mozilla.org
QA Contact: granrosebugs → mozillabuild
Version: Trunk → other
RESOLVED DONTCARE ? Whatever's in MozillaBuild seems to be working.
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.