patches for xerces on GNU/kFreeBSD (fwd)

[Petr Salinger]

Hi.

> > They are submitted in BTS within
> > Bug#335204: xerces26: FTBFS on GNU/kFreeBSD
> > Bug#335205: xerces25: FTBFS on GNU/kFreeBSD
> 
> I would suggest to avoid creating new files with duplicated code from another
> one, like KFreeBSDPlatformUtils.cpp.  This is in most cases unnecessary, and
> leads to unsyncronisation, and eventualy to breakage (which will need extra
> debugging effort to figure out what happens).

Yes, you are right, but I just followed upstream style 
for multi-platform support in xerces 2.x series: 

$ ls xerces-c-src_2_6_0/src/xercesc/util/Platforms
AIX  BeOS  Cygwin  FreeBSD  HPUX  IRIX  Interix  Linux  MacOS  Makefile.in  
NetBSD  OS2  OS390  OS400  OpenServer  PTX  QNX  Solaris  Tandem  Tru64  UnixWare  Win32

> The following line in debian/rules points to a "linux" case:
> 
> -                sh runConfigure -plinux -cgcc -xg++ -minmem -ticu \
> 
> Is that "linux" case really linux-specific?  Or just dependant on GNUish
> userland stuff like Glibc?  If it's the latter, you can probably port xerces
> by just changing a pair of lines in that file.

It is mainly glibc userland, but
 
* the platform argument (-plinux) from runConfigure is not passed to ./configure.
* Platforms/Linux/LinuxDefs.hpp defines LINUX
* util/AutoSense.hpp depends directly  on __linux__ 

>From my point of view is better to follow upstream style for 
multi-platform support and create own "Platform".

But the problem of code unsynchronisation can be partially addressed:
* Linux/LinuxPlatformUtils.cpp will include <sys/param.h> instead of <linux/limits.h>
* KFreeBSD/KFreeBSDPlatformUtils.cpp then can be changed into #include "../Linux/LinuxPlatformUtils.cpp"

The multi-platform support in future xerces 3.x series is reworked and 
snapshot xerces-c_20051021105601 builds fine without patching.
May be etch will be release with xerces 3.x only.

Petr