[cvsnt-dev] Bug in cvsnt 2.5.03.2151 kills Codepage Translation under HPUX

[Jan Giesen]

Dear Tony,

Some day ago I have written:
> I have made some few test with cvsnt 2.5.03.2151 running as server under
> HPUX. It seems that the "fileattr.xml" files in the CVS directories
> on the server are not correctly constructed under HPUX. Some "chacl"
> commands in sequence produce malformed XML files on the server.
> This problem under HPUX was already reported some time ago on the
> cvsnt list. Probably this is caused by the "expat" version in the
> cvsnt repository, which is under Linux normally not used, since libexpat
> is available on the system.

The problem is not caused by a wrong "expat" version, but caused by the
fact that cvsnt is not linked properly with the GNU "libiconv" library
under HPUX. Therefore the codepage translation from HP-ROMAN8 to UTF-8
fails and the data fields in the "fileattr.xml" file are not filled,
since cvsnt tries to convert usernames etc. to UTF-8 before storing in
"fileattr.xml".

Instead of the GNU libiconv functions (libiconv(), libiconv_open(), ...)
the HPUX iconv functions (iconv(), iconv_open(),...) are linked in.
This is caused by a "#define bug" in diff/unicodeapi.c and
cvsapi/Codepage.cpp:

You define:
#ifndef HAVE_LIBICONV
#define LIBICONV_PLUG
#endif

But the parameter "HAVE_LIBICONV" is nowhere defined, therefore
"LIBICONV_PLUG" becomes defined, which prohibits later the mapping from
iconv() -> libiconv() etc. in <iconv.h>.
The cvsnt "configure" script generates only a "config.h" file, in which
the parameter "HAVE_LIBICONV_OPEN" is defined, in case GNU libiconv is found
on the system.

Renaming HAVE_LIBICONV to HAVE_LIBICONV_OPEN in "unicodeapi.c" and
"Codepage.cpp" solves the problem: The correct GNU libiconv routines are
found,
the codepage translation from HP-ROMAN8 to UTF-8 is carried out and the
"fileattr.xml" files are generated correctly.

Best regards
                    Jan Giesen