Re: problems building feature release on windows

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kelly F. Hickel <kfh@mqsoftware.com> writes:

> > -----Original Message-----
> > On Behalf Of Mark D. Baushke
> > 
> <snip>
> > 
> > I am under the impression that most of the wide
> > character support functions should not be needed.
> > They would only be getting referenced from
> > lib/regcomp.c or lib/fnmatch.c or
> > lib/fnmatch_loop.c and the equivalent code for all
> > of the functions provided by those files should be
> > getting built in the windows-NT directory.
> > 
> > > Windows is (more or less) windows, the library
> > > support hasn't changed all that much between
> > > recent compiler releases (ok, ok, so it's
> > > changed, don't shoot me, it hasn't *really*
> > > changed *that* much ;->).
> > 
> > Sure.
> > 
> > > When I looked at the areas where the unresolved
> > > symbols were coming from, there didn't seem to
> > > be any ifdefs around the use of these functions,
> > > and the Windows-NT/config.h specifically undef'd
> > > HAVE_BTOWC to no avail.
> > 
> > The lib/* functions are presumed to be
> > compatibility functions that will work reasonably
> > portably when the operating system does not
> > provide the function needed. I suppose it is
> > possible we are yet missing some GNULIB
> > compatibility functions, but I would not have
> > expected wide character manipulation routines to
> > be among their number as I would not have expected
> > them to be needed.
> 
> [Kelly F. Hickel] I was a bit surprised as well,
> the code I stuck in to resolve the symbols will
> print messages to stdout if called, and it
> hasn't yet, so they don't seem to be needed so
> far in what I'm doing.

Okay.

> > > > > When I do that the resulting .exe seems to
> > > > > work but doesn't actually do anything with
> > > > > any of the files in the directories of the
> > > > > repo. So, if I do a co, I get all the
> > > > > directories and CVS directories, but no
> > > > > files.
> > > >
> > > > If you wish to send e-mail with the
> > > > compilation errors you are getting, we might
> > > > be able to fix things.
> > >

> > > [Kelly F. Hickel] Attached is a full output
> > > of "nmake /f cvsnt.mak" of an unmodified
> > > 1.12.13 tarball.
> > 
> > Sadly, this file will not have been included for
> > the general readers of the bug-cvs mailing list as
> > it seems that attachments are stripped by the
> > mailing list software.
> > 
> > It seems that regex.obj is being created with a
> > _btowc reference out of _re_compile_fastmap_iter
> > 
> > libdiff.lib(regex.obj) : error LNK2019: unresolved external symbol
> > _btowc referenced in function _re_compile_fastmap_iter
> > libdiff.lib(regex.obj) : error LNK2019: unresolved external symbol
> > _wcrtomb referenced in function _re_compile_fastmap_iter
> > libdiff.lib(regex.obj) : error LNK2019: unresolved external symbol
> > _mbrtowc referenced in function _re_compile_fastmap_iter
> > libdiff.lib(strcasecmp.obj) : error LNK2001: unresolved external
> > symbol _mbrtowc
> > libdiff.lib(quotearg.obj) : error LNK2001: unresolved external symbol
> > _mbrtowc
> > libdiff.lib(regex.obj) : error LNK2019: unresolved external symbol
> > _wctype referenced in function _build_charclass
> > libdiff.lib(strftime.obj) : error LNK2019: unresolved external symbol
> > _mbrlen referenced in function _nstrftime
> > .\WinDebug\cvs.exe : fatal error LNK1120: 5 unresolved externals
> > NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
> > 
> > I am given to understand that windows <wchar.h> does support
> > mbrtowc().
> > 
> > Does your system have an mbrtowc and mbrlen
> > 
> >   http://msdn2.microsoft.com/en-us/library/5wazc5ys(VS.80).aspx
> > 
> > seems to indicate that it should have one somewhere...
> 
> [Kelly F. Hickel] I found that link yesterday as
> well. I spent a fair amount of time trying to
> figure out why the symbols weren't around. In
> the end, I've decided (based on examining the
> exported symbols of various MSVC .lib and .dll
> files) that those functions are available in the
> C++ runtime, but not in the C runtime.

Hmmm... Okay, I guess we need to wait until one of
the folks who builds CVS on Windows tells us what
they used.

> > > > In the mean time, you should be able to
> > > > download CVS 1.12.13 in either source or
> > > > binary form for Windows and use it without any
> > > > problems.
> > >
> > > [Kelly F. Hickel] Yes, I use the binary with no
> > > issues. My real goal here is to run a tag
> > > operation from Quantify so I can see where all
> > > the cpu time is going. Right now it takes two
> > > hours to do a branch tag on our repo. This may
> > > be a lost cause, but I didn't think it would
> > > take very long to give it a try and have a look
> > > (silly me!).
> > 
> > Hmmm... a branch tag will need to open and write
> > all of the ,v files in the repository and this
> > operation will be happening on the server.
> > 
> > As the windows binary for 1.12.12 and 1.12.13 is a
> > client-only binary, I know that some other cvs
> > server is doing the taggging. You should be able
> > to take a look at the time it takes for cvs to do
> > the job on the server to see how much is related
> > to client-side problems and how much is the server
> > side.
> 
> [Kelly F. Hickel] Yes, I'd rather be quantifying
> the pserver implementation on my linux box, but
> I don't have a linux license for Quantify. In my
> tests, doing a branch tag against a local file
> repo takes as long as pserver does, so I've
> copied the repo down to windows and plan to
> Quantify a build running against that.

Ahh.. Okay.

> One very odd thing that I have no explanation
> for is that I moved from a 4 way 700mhz PIII to
> a 2 way 2.4 mhz PIV and it takes roughly the
> same amount of time. The only inkling of an
> explanation is that I was running cvspserver
> 1.11.x on the PIII and am running 1.12.13 on the
> PIV. The cvs process is definitely CPU bound
> during this operation (according to top and
> xosview).

It will be reading the existing files and copying
them in to temporary ,filename, files and adding
the new tag along the way. I would have thought
that operation would be more IO bound than CPU
bound, but I have not looked at it closely in a
long time.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEV7p6Cg7APGsDnFERAmK/AJ9YU2nuPXkYVPL9V77bV+hPZqBjvgCg0VoZ
ArMovpUJLUENTYvxpDM4kcI=
=NPN/
-----END PGP SIGNATURE-----