cvs emacs build fails on Windows XP
Martin Stemplinger
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
jasonr
> 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.
Timur Aydin
>> 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
jasonr
> 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.
Eli Zaretskii
> From: Timur Aydin <t...@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).
Bart Oldeman
> > Newsgroups: gnu.emacs.help
> > From: Timur Aydin <t...@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
jasonr
> 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,
That is where the CVS model breaks. When an Emacs distribution is put
together, the code is exported onto a GNU machine, and tarred up from
there. So the batch files MUST have DOS line ends in the repository.
Making them binary causes more breakage in CVS than it is worth.
Eli Zaretskii
> Newsgroups: gnu.emacs.help
> Date: 1 Jul 2003 04:00:17 -0700
> >
> > 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
No, it isn't: suppose you then prepare a tarball of the distribution,
and that tarball needs to be built on Windows using those batch files.
(This is an actual problem with Emacs, for example.)
> 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
Yes, but edit them with a Windows editor (other than Emacs), and
chances are you will have CR-LF pairs or even mixed LF and CR-LF
lines. It's a mess.
Bart Oldeman
> > From: bart.o...@bristol.ac.uk (Bart Oldeman)
> > Newsgroups: gnu.emacs.help
> > Date: 1 Jul 2003 04:00:17 -0700
> > >
> > > 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
>
> No, it isn't: suppose you then prepare a tarball of the distribution,
> and that tarball needs to be built on Windows using those batch files.
> (This is an actual problem with Emacs, for example.)
what you are "supposed" to do then it to do on the fly eol conversion
-- the source code for Windows then uses CRLF for all text files and
not just batch files. Like the "-l" option of InfoZIP's zip.
Staying with the philosophy of "different platforms, different text
file formats"...
It's just that emacs wants to distribute *one* source tarball for all
platforms that makes this a problem. In CVS's way of thinking one
would produce, say, a .tar.gz for Unix with LF line endings, a zip for
Windows with cr-lf line endings, another format for VMS and so on...
Somebody submitted a patch to the CVS developers a couple of years ago
that can make the cvs client on Unix behave like one on Win32 and vice
versa. The CVS developers didn't like it. With this status quo there
doesn't seem to be a good solution in sight.
patch:
http://www.geocrawler.com/archives/3/383/2000/12/0/4826403/
reply from Larry Jones
http://www.geocrawler.com/archives/3/383/2000/12/0/4826709/
Not that I disagree with you about making one source tarball -- this
is just something to be careful about (particularly if you start using
$Log in batch files -- you'll see that the server will add LF line
endings).
Bart
Eli Zaretskii
> > >
> > > 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
> >
> > No, it isn't: suppose you then prepare a tarball of the distribution,
> > and that tarball needs to be built on Windows using those batch files.
> > (This is an actual problem with Emacs, for example.)
>
> what you are "supposed" to do then it to do on the fly eol conversion
> -- the source code for Windows then uses CRLF for all text files and
> not just batch files. Like the "-l" option of InfoZIP's zip.
That's not good: the same tarball, prepared on Unix, should be used
on both Unix and Windows (and on Mac), so all the text files should
be in Unix EOL format, except for batch files.
> It's just that emacs wants to distribute *one* source tarball for all
> platforms that makes this a problem. In CVS's way of thinking one
> would produce, say, a .tar.gz for Unix with LF line endings, a zip for
> Windows with cr-lf line endings, another format for VMS and so on...
If that's ``the CVS way of thinking'', then it seems like CVS wants
the rest of the world to bend to comply to CVS's misfeatures. That's
not how, in my mind, one should solve problems.
> if you start using $Log in batch files -- you'll see that the server
> will add LF line endings
Another misfeature, IMHO.