RE: problems building feature release on windows

[Kelly F. Hickel]

> -----Original Message-----
> From: mdb@juniper.net [mailto:mdb@juniper.net] 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.

> 
> > > > 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.

> 
> > > 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.

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).

> 
> > > > This stuff must build, right? I can download
> > > > binaries that work fine, so someone must
> > > > have built it......
> > >
> > > Indeed. 1.12.12 and 1.12.13 did build, but I
> > > do not have details on the nature of the
> > > environment used.
> > >
> > >   -- Mark
> > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Kelly F. Hickel
> > > > Senior Software Architect
> > > > MQSoftware, Inc
> > > > 952.345.8677
> > > > kfh@mqsoftware.com
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.3 (FreeBSD)
> > >
> > > iD8DBQFEV6mkCg7APGsDnFERAgKzAJ0SDiNaMh9Tis26qhcdSudXlw99xgCg1aWH
> > > Ulg8bT2fNmAxi2NVixLTBes=
> > > =sgYf
> > > -----END PGP SIGNATURE-----
> >
> > --
> >
> > Kelly F. Hickel
> > Senior Software Architect
> > MQSoftware, Inc
> > 952.345.8677
> > kfh@mqsoftware.com
> >
> > _______________________________________________
> > Bug-cvs mailing list
> > Bug-cvs@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/bug-cvs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (FreeBSD)
> 
> iD8DBQFEV7N1Cg7APGsDnFERAmWhAKCj2YBseSyO+iAaSKSyVWbNFLSMfACfSQ2A
> mVmQPNofp8RLMdog5ATaE8k=
> =feGV
> -----END PGP SIGNATURE-----

-- 

Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677
kfh@mqsoftware.com