cvs emacs build fails on Windows XP

cvs emacs build fails on Windows XP

[Martin Stemplinger]

I don't know if this is the right place to ask. If not, I apologize in
advance and I would be glad to get a pointer to the correct place.

I tried to compile Emacs from CVS on Windows XP using Visual Studio
.NET.

As documented I did a configure.bat followed by nmake bootstrap and it
fails during linking with the message

link -out:obj-spd/i386/temacs.bin -release -incremental:no
-version:3.10 -swaprun:cd -swaprun:net setargv.obj -debug:full
-debugtype:both  -stack:0x00800000 -heap:0x00100000 -base:0x01000000
-debug:full -debugtype:both -pdb:obj-spd/i386\temacs.pdb -machine:i386
-subsystem:console -entry:_start -map:obj-spd/i386\temacs.map -profile
obj-spd/i386/firstfile.obj obj-spd/i386/emacs.res
obj-spd/i386/temacs0.lib	 obj-spd/i386/temacs1.lib
obj-spd/i386/temacw32.lib	 obj-spd/i386/lastfile.lib
winmm.lib     advapi32.lib	 gdi32.lib	 comdlg32.lib
user32.lib	 mpr.lib		 shell32.lib	 libc.lib 
Microsoft (R) Incremental Linker Version 7.10.2292
Copyright (C) Microsoft Corporation.  All rights reserved. 

LINK : warning LNK4224: /DEBUGTYPE:BOTH is no longer supported;
ignored 
LINK : warning LNK4224: /DEBUGTYPE:BOTH is no longer supported;
ignored 
libc.lib(strftime.obj) : error LNK2005: _strftime already defined in
temacs1.lib(strftime.obj) 
obj-spd/i386/temacs.bin : fatal error LNK1169: one or more multiply
defined symbols found 

Any ideas what went wrong? I had to manually change the line-endings
(I guess this was due to fetching the source from cvs). Could that be
the problem?

Martin

Re: cvs emacs build fails on Windows XP

[Jason Rumney]

Martin Stemplinger <mstemplinger@gmx.de> writes:

> I don't know if this is the right place to ask. If not, I apologize in
> advance and I would be glad to get a pointer to the correct place.

If you have problems with the CVS version, you should first check the
emacs-devel and emacs-pretest-bug mailing lists (archives are at
http://mail.gnu.org/ and http://news.gmane.org/). If your problem is
not already being talked about there, then report it using Emacs'
built in bug reporting capability. That will ensure the report goes
to the correct place.


> I had to manually change the line-endings (I guess this was due to
> fetching the source from cvs).

That is neccesary in the nt and leim/CXTERM subdirectories if you use
a DOS/Windows CVS client that changes the line-ends as it checks
out. Recent versions of WinCVS and any version of Cygwin CVS can work
in a mode where they do not change line-ends.

Re: cvs emacs build fails on Windows XP

[Timur Aydin]

jasonr (Jason Rumney) @  f2s.com writes:

>> I had to manually change the line-endings (I guess this was due to
>> fetching the source from cvs).
>
> That is neccesary in the nt and leim/CXTERM subdirectories if you use
> a DOS/Windows CVS client that changes the line-ends as it checks
> out. Recent versions of WinCVS and any version of Cygwin CVS can work
> in a mode where they do not change line-ends.

cvs does change line ending according to the underlying platform. This
is by design. A properly added file will be stored on the cvs server
with LF line endings. When checking out, the file will be converted to
have CR/LF line endings under windows, LF line endings under unix (no
change) and LF/CR line endings uder MAC. Properly adding a text file
means adding it while it has the correct line endings for the
underlying platform.

It seems the nt related files and the leim dictionary files have not
been added to the repository properly. They probably have been added
to the cvs repository under linux, while having CR/LF line endings, or
something like that.

-- 
Timur Aydin

Re: cvs emacs build fails on Windows XP

[Jason Rumney]

Timur Aydin <ta@taydin.org> writes:

> cvs does change line ending according to the underlying platform. This
> is by design. A properly added file

For some definition of properly. But when you need to produce source
tarballs from your source tree that compile correctly on all
platforms, then those files need to have CRLF line ends when checked
out on the machine where the tarball is made.

Re: cvs emacs build fails on Windows XP

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Timur Aydin <ta@taydin.org>
> Date: Sat, 28 Jun 2003 17:12:24 +0300
> 
> cvs does change line ending according to the underlying platform. This
> is by design.

A quite broken design, I'd say.

> A properly added file will be stored on the cvs server
> with LF line endings. When checking out, the file will be converted to
> have CR/LF line endings under windows, LF line endings under unix (no
> change) and LF/CR line endings uder MAC.

And what would this do to Widnows *.bat batch files, that are already
in CR/LF format, and should stay that way (or else some versions of
Windows shells will refuse to run them), including in the repository?

IMHO, a design of a distributed version-control package which doesn't
take into account that files will be checked in and out from clients
running on different platforms, and that some files need to be in
non-Unix end-of-line format -- such a design is Unix-centric (read:
broken).

Re: cvs emacs build fails on Windows XP

[Bart Oldeman]

"Eli Zaretskii" <eliz@elta.co.il> wrote in message news:<mailman.8828.1056857204.21513.help-gnu-emacs@gnu.org>...
> > Newsgroups: gnu.emacs.help
> > From: Timur Aydin <ta@taydin.org>
> > Date: Sat, 28 Jun 2003 17:12:24 +0300
> > 
> > cvs does change line ending according to the underlying platform. This
> > is by design.
> 
> A quite broken design, I'd say.
> 
> > A properly added file will be stored on the cvs server
> > with LF line endings. When checking out, the file will be converted to
> > have CR/LF line endings under windows, LF line endings under unix (no
> > change) and LF/CR line endings uder MAC.
> 
> And what would this do to Widnows *.bat batch files, that are already
> in CR/LF format, and should stay that way (or else some versions of
> Windows shells will refuse to run them), including in the repository?

no, they should have LF endings in the repository. Play with $Log RCS
keywords and you see what I mean. Or make them "binary" using "cvs
admin -kb" but that's strange.

You check batch files out on Windows, LF is converted to CRLF, all
is fine.

You check batch files out on Unix, LF stays LF, and all is fine, because
you cannot run the batch files in Unix anyway (well unless you start
playing with Wine or DOSEMU, but those are different platforms so
then you should use a DOS or Windows CVS client in DOSEMU or Wine).
Then you can *edit* the batch file on Unix with any editor (not just
newer Emacs versions for instance) and LFs stay LFs. Check them in
again, and a Windows CVS client retrieves the batch files and 
has the correct format.

This makes sense especially if you realize that this problem goes
beyond line endings and you think about EBCDIC and VMS.

It just happens to be the case that most DOS and Windows compilers
(but Turbo C 2.01 is an exception for instance) accept C files
with LF line endings, that for Emacs you can enforce a policy of
not changing line endings between client and server.

That's the theory and it makes sense. In practise many people
like to do the "idiotic" thing (according to some of the CVS 
developers, search google if you like) of sharing the same 
working directory among different platforms which is exactly
what Emacs tries to do by providing this one universal source
tarball that is unpacked in binary mode on both Windows and
Unix. So this "idiotic" thing makes sense too :)

Bart