kc3-lang/libxml2/win32

Diff

  • Show log

    Commit

  • Hash : 5706b6d8
    Author : Daniel Richard G
    Date : 2012-08-06T11:32:54 

    Various "make distcheck" and portability fixups

Makefile.am:

* Don't use @VAR@, use $(VAR). Autoconf's AC_SUBST provides us the Make
   variable, it allows overriding the value at the command line, and
   (notably) it avoids a Make parse error in the libxml2_la_LDFLAGS
   assignment when @MODULE_PLATFORM_LIBS@ is empty

* Changed how the THREADS_W32 mechanism switches the build between
   testThreads.c and testThreadsWin32.c as appropriate; using AM_CONDITIONAL
   allows this to work cleanly and plays well with dependencies

* testapi.c should be specified as BUILT_SOURCES

* Create symlinks to the test/ and result/ subdirs so that the runtests
   target is usable in out-of-source-tree builds

* Don't do MAKEFLAGS+=--silent as this is not portable to non-GNU Makes

* Fixed incorrect find(1) syntax in the "cleanup" rule, and doing "rm -f"
   instead of just "rm" is good form

* (DIST)CLEANFILES needed a bit more coverage to allow "make distcheck" to
   pass

configure.in:

* Need AC_PROG_LN_S to create test/ and result/ symlinks in Makefile.am

* AC_LIBTOOL_WIN32_DLL and AM_PROG_LIBTOOL are obsolete; these have been
   superceded by LT_INIT

* Don't rebuild docs by default, as this requires GNU Make (as
   implemented)

* Check for uint32_t as some platforms don't provide it

* Check for some more functions, and undefine HAVE_MMAP if we don't also
   HAVE_MUNMAP (one system I tested on actually needed this)

* Changed THREADS_W32 from a filename insert into an Automake conditional

* The "Copyright" file will not be in the current directory if builddir !=
   srcdir

doc/Makefile.am:

* EXTRA_DIST cannot use wildcards when they refer to generated files; this
   breaks dependencies. What I did was define EXTRA_DIST_wc, which uses GNU
   Make $(wildcard) directives to build up a list of files, and EXTRA_DIST,
   as a literal expansion of EXTRA_DIST_wc. I also added a new rule,
   "check-extra-dist", to simplify checking that the two variables are
   equivalent. (Note that this works only when builddir == srcdir)

   (I can implement this differently if desired; this is just one way of
   doing it)

* Don't define an "all" target; this steps on Automake's toes

* Fixed up the "libxml2-api.xml ..." rule by using $(wildcard) for
   dependencies (as Make doesn't process the wildcards otherwise) and
   qualifying appropriate files with $(srcdir)

   (Note that $(srcdir) is not needed in the dependencies, thanks to VPATH,
   which we can count on as this is GNU-Make-only code anyway)

doc/devhelp/Makefile.am:

* Qualified appropriate files with $(srcdir)

* Added an "uninstall-local" rule so that "make distcheck" passes

doc/examples/Makefile.am:

* Rather than use a wildcard that doesn't work, use a substitution that
   most Make programs can handle

doc/examples/index.py:

* Do the same here

include/libxml/nanoftp.h:

* Some platforms (e.g. MSVC 6) already #define INVALID_SOCKET:

     user@host:/cygdrive/c/Program Files/Microsoft Visual Studio/VC98/\
     Include$ grep -R INVALID_SOCKET .
     ./WINSOCK.H:#define INVALID_SOCKET  (SOCKET)(~0)
     ./WINSOCK2.H:#define INVALID_SOCKET  (SOCKET)(~0)

include/libxml/xmlversion.h.in:

* Support ancient GCCs (I was actually able to build the library with 2.5
   but for this bit)

python/Makefile.am:

* Expanded CLEANFILES to allow "make distcheck" to pass

python/tests/Makefile.am:

* Define CLEANFILES instead of a "clean" rule, and added tmp.xml to allow
   "make distcheck" to pass

testRelax.c:

* Use HAVE_MMAP instead of the less explicit HAVE_SYS_MMAN_H (as some
   systems have the header but not the function)

testSchemas.c:

* Use HAVE_MMAP instead of the less explicit HAVE_SYS_MMAN_H

testapi.c:

* Don't use putenv() if it's not available

threads.c:

* This fixes the following build error on Solaris 8:

     libtool: compile:  cc -DHAVE_CONFIG_H -I. -I./include -I./include \
     -D_REENTRANT -D__EXTENSIONS__ -D_REENTRANT -Dsparc -Xa -mt -v \
     -xarch=v9 -xcrossfile -xO5 -c threads.c  -KPIC -DPIC -o threads.o
     "threads.c", line 442: controlling expressions must have scalar type
     "threads.c", line 512: controlling expressions must have scalar type
     cc: acomp failed for threads.c
     *** Error code 1

trio.c:

* Define isascii() if the system doesn't provide it

trio.h:

* The trio library's HAVE_CONFIG_H header is not the same as LibXML2's
   HAVE_CONFIG_H header; this change is needed to avoid a double-inclusion

win32/configure.js:

* Added support for the LZMA compression option

win32/Makefile.{bcb,mingw,msvc}:

* Added appropriate bits to support WITH_LZMA=1

* Install the header files under $(INCPREFIX)\libxml2\libxml instead of
   $(INCPREFIX)\libxml, to mirror the install location on Unix+Autotools

xml2-config.in:

* @MODULE_PLATFORM_LIBS@ (usually "-ldl") needs to be in there in order for
   `xml2-config --libs` to provide a complete set of dependencies

xmllint.c:

* Use HAVE_MMAP instead of the less-explicit HAVE_SYS_MMAN_H

  • Readme.txt

  •                              Windows port
                             ============

This directory contains the files required to build this software on the
native Windows platform. This is not a place to look for help if you are
using a POSIX emulator, such as Cygwin. Check the Unix instructions for 
that.



CONTENTS
========

1. General
   1.1 Building From the Command-Line
   1.2 Configuring The Source
   1.3 Compiling
   1.4 Installing

2. Compiler Specifics
   2.1 Microsoft Visual C/C++
   2.1 GNU C/C++, Mingw Edition
   2.2 Borland C++ Builder
       2.2.1 Building with iconv support
	   2.2.2 Compatability problems with MSVC (and probably CYGWIN)
	   2.2.3 Other caveats




1. General
==========


1.1 Building From The Command-Line
----------------------------------

This is the easiest, preferred and currently supported method. It can
be that a subdirectory of the directory where this file resides 
contains project files for some IDE. If you want to use that, please
refer to the readme file within that subdirectory.

In order to build from the command-line you need to make sure that
your compiler works from the command line. This is not always the
case, often the required environment variables are missing. If you are
not sure, test if this works first. If it doesn't, you will first have
to configure your compiler suite to run from the command-line - please
refer to your compiler's documentation regarding that.

The first thing you want to do is configure the source. You can have
the configuration script do this automatically for you. The
configuration script is written in JScript, a Microsoft's
implementation of the ECMA scripting language. Almost every Windows
machine can execute this through the Windows Scripting Host. If your
system lacks the ability to execute JScript for some reason, you must
perform the configuration manually and you are on your own with that.

The second step is compiling the source and, optionally, installing it
to the location of your choosing.


1.2 Configuring The Source
--------------------------

The configuration script accepts numerous options. Some of these
affect features which will be available in the compiled software,
others affect the way the software is built and installed. To see a
full list of options supported by the configuration script, run

  cscript configure.js help

from the win32 subdirectory. The configuration script will present you
the options it accepts and give a biref explanation of these. In every
case you will have two sets of options. The first set is specific to
the software you are building and the second one is specific to the
Windows port.

Once you have decided which options suit you, run the script with that
options. Here is an example:

  cscript configure.js compiler=msvc prefix=c:\opt 
    include=c:\opt\include lib=c:\opt\lib debug=yes

The previous example will configure the process to use the Microsoft's
compiler, install the library in c:\opt, use c:\opt\include and 
c:\opt\lib as additional search paths for the compiler and the linker 
and build executables with debug symbols.

Note: Please do not use path names which contain spaces. This will
fail. Allowing this would require me to put almost everything in the
Makefile in quotas and that looks quite ugly with my
syntax-highlighting engine. If you absolutely must use spaces in paths
send me an email and tell me why. If there are enough of you out there
who need this, or if a single one has a very good reason, I will
modify the Makefile to allow spaces in paths.


1.3 Compiling
-------------

After the configuration stage has been completed, you want to build
the software. You will have to use the make tool which comes with
your compiler. If you, for example, configured the source to build
with Microsoft's MSVC compiler, you would use the NMAKE utility. If
you configured it to build with GNU C compiler, mingw edition, you
would use the GNU make. Assuming you use MSVC, type

  nmake /f Makefile.msvc

and if you use MinGW, you would type

  make -f Makefile.mingw

and if you use Borland's compiler, you would type

  bmake -f Makefile.bcb

in the win32 subdirectory. When the building completes, you will find
the executable files in win32\bin.* directory, where * stands for the
name of the compiler you have used.


1.4 Installing
--------------

You can install the software into the directory you specified to the
configure script during the configure stage by typing (with MSVC in
this example)

  nmake /f Makefile.msvc install

That would be it, enjoy.





2. Compiler Specifics
=====================


2.1 Microsoft Visual C/C++
--------------------------

If you use the compiler which comes with Visual Studio .NET, note that
it will link to its own C-runtime named msvcr70.dll or msvcr71.dll. This 
file is not available on any machine which doesn't have Visual Studio 
.NET installed.


2.2 GNU C/C++, Mingw edition
----------------------------

When specifying paths to configure.js, please use slashes instead of 
backslashes for directory separation. Sometimes Mingw needs this. If
this is the case, and you specify backslashes, then the compiler will 
complain about not finding necessary header files.


2.2 Borland C++ Builder
-----------------------

To compile libxml2 with the BCB6 compiler and associated tools, just follow
the basic instructions found in this file file. Be sure to specify 
the "compiler=bcb" option when running the configure script. To compile the
library and test programs, just type

  make -fMakefile.bcb

That should be all that's required. But there are a few other things to note:

2.2.1 Building with iconv support

If you configure libxml2 to include iconv support, you will obviously need to
obtain the iconv library and include files. To get them, just follow the links 
at http://www.gnu.org/software/libiconv/ - there are pre-compiled Win32 
versions available, but note that these where built with MSVC. Hence the 
supplied import library is in COFF format rather than OMF format. You can 
convert this library by using Borland's COFF2OMF utility, or use IMPLIB to 
build a new import library from the DLL. Alternatively, it is possible to
obtain the iconv source, and build the DLL using the Borland compiler.

There is a minor problem with the header files for iconv - they expect a
macro named "EILSEQ" in errno.h, but this is not defined in the Borland
headers, and its absence can cause problems. To circumvent this problem, I
define EILSEQ=2 in Makefile.bcb. The value "2" is the value for ENOFILE (file
not found). This should not have any disastrous side effects beyond possibly
displaying a misleading error message in certain situations.

2.2.2 Compatability problems with MSVC (and probably CYGWIN)

A libxml2 DLL generated by BCB is callable from MSVC programs, but there is a
minor problem with the names of the symbols exported from the library. The
Borland compiler, by default, prepends an underscore character to global 
identifiers (functions and global variables) when generating object files.
Hence the function "xmlAddChild" is added to the DLL with the name
"_xmlAddChild". The MSVC compiler does not have this behaviour, and looks for
the unadorned name. I currently circumvent this problem by writing a .def file
which causes BOTH the adorned and unadorned names to be exported from the DLL.
This behaviour may not be supported in the future.

An even worse problem is that of generating an import library for the DLL. The
Borland-generated DLL is in OMF format. MSVC expects libraries in COFF format,
but they don't provide a "OMF2COFF" utility, or even the equivalent of
Borland's IMPLIB utility. But it is possible to create an import lib from the
.def file, using the command:
  LIB /DEF:libxml2.def

If you don't have the .def file, it's possible to create one manually. Use
DUMPBIN /EXPORTS /OUT:libxml2.tmp libxml2.dll to get a list of the exported
names, and edit this into .def file format.

A similar problem is likely with Cygwin.

2.2.3 Other caveats

We have tested this only with BCB6, Professional Edition, and BCB 5.5 free
command-line tools.



Authors: Igor Zlatkovic <igor@zlatkovic.com>
         Eric Zurcher <Eric.Zurcher@csiro.au>

kmx.io     mail     discord kmxgit v0.4.0