-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kelly F. Hickel <[EMAIL PROTECTED]> 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----- _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
