[xml] Building libxml2 with the Borland/CodeGear/Embarcadero toolset

Hello Daniel et al.

It has been a while since I've tried compiling libxml2 with the "Borland" (the compilers are now in the hands 
of Embarcadero) C compiler, but I've recently had reason to do so, and have a few very minor patches that I'd 
like to apply. I've been using the compiler and toolset distributed with Rad Studio 2007 and later patches: 
CodeGear C/C++ compiler 5.93, incremental linker 5.81, library manager 5.1. 

The first problem is nearly identical with one I reported on this forum just over 3 years ago. It's not a 
problem with libxml2, but rather with one of the CodeGear header files: WSPiApi.h (in fairness to 
Embarcadero, the header file comes from Microsoft, so it's really a Microsoft bug). The "inlining" directive 
in the declaration of the function WspiapiStrdup is incorrect: it is given as "_inline", but ought to be 
"__inline". My suggested patch is a minor change in wsockcompat.h

Index: wsockcompat.h
--- wsockcompat.h       (revision 3815)
+++ wsockcompat.h       (working copy)
@@ -15,6 +15,7 @@
    header when compiled with Borland C++ 6 */
 #if defined(__BORLANDC__) && !defined(__cplusplus)
 #define inline __inline
+#define _inline __inline
 #include <ws2tcpip.h>

A second problem are 2 minor changes needed in the template Makefile for BCB. The first adds a directory to 
the LIB search path; the second adds a library.

Index: Makefile.bcb
--- Makefile.bcb        (revision 3815)
+++ Makefile.bcb        (working copy)
@@ -72,7 +72,7 @@
 # The linker and its options.
 LD = ilink32.exe
+LDFLAGS = $(LDFLAGS) -L"$(BINDIR);$(LIBPREFIX);$(LIB);$(BCB)\lib;$(BCB)\lib\PSdk"
 LIBS = import32.lib
 !if "$(WITH_THREADS)" != "no" && "$(DYNRUNTIME)" == "1"
 LIBS = $(LIBS) cw32mti.lib
@@ -84,7 +84,7 @@
 LIBS = $(LIBS) cw32.lib
 !if "$(WITH_FTP)" == "1" || "$(WITH_HTTP)" == "1"
-LIBS = $(LIBS) wsock32.lib
+LIBS = $(LIBS) wsock32.lib ws2_32.lib
 !if "$(WITH_ICONV)" == "1"
 LIBS = $(LIBS) iconvomf.lib

Finally, running the test suite revealed a problem in xpath.c. Within the function xmlXPathSubstringFunction, 
there is a test for whether both arguments are infinity, which (as indicated by the comments near the test) 
relies on Inf + -Inf yielding NaN. However, by default the CodeGear run-time initializes the floating-point 
control word to enable "floating point invalid" exceptions, so attempting the Inf + -Inf operation raises an 
exception, rather than quietly generating NaN as a result. This problem can be eliminated by reversing the 
order of evaluation, as in the patch below. 

Index: xpath.c
--- xpath.c     (revision 3815)
+++ xpath.c     (working copy)
@@ -9020,7 +9020,7 @@
      * the index is NaN, the length is NaN, or both
      * arguments are infinity (relying on Inf + -Inf = NaN)
-    if (!xmlXPathIsNaN(in + le) && !xmlXPathIsInf(in)) {
+    if (!xmlXPathIsInf(in) && !xmlXPathIsNaN(in + le)) {
          * To meet the requirements of the spec, the arguments
         * must be converted to integer format before

Can these patches be applied?


Eric Zurcher
CSIRO Plant Industry
Canberra, Australia
Eric Zurcher csiro au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]