Re: problems building feature release on windows

[Mark D. Baushke]

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


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

> > > The .dsp/.dsw files won't load into either
> > > version of VS .net that I have, it reports
> > > that the project files are corrupt.
> > 
> > Very strange. I believe that both 1.12.12 and
> > 1.12.13 were building without any problems on
> > Windows. Conrad T Pino should be able to tell
> > you more about the environment he used for
> > building.
> > 
> >     -- Mark
> > 
> > > When I use the .mak files, I can get it to
> > > build if I add code for some of the wide
> > > character stuff (btowc, mbrtowc and wctype)
> > > which don't seem to be supplied.
> > 
> > My guess is that your config.h needs to be
> > adjusted. I would have expected '#undef
> > HAVE_BTOWC' to exist and avoid problems with
> > that.

> > The current revision of windows-NT/config.h
> > does appear to define HAVE_MBRTOWC and
> > HAVE_WCTYPE_H, so if your system does not, you
> > may need to adjust those values.
> 
> [Kelly F. Hickel] AFAICT there are no
> adjustments to make to Windows-NT/config.h, and
> the README doesn't mention any.

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.

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

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

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