|
Actions:
|
2008-02-13 16:06 AEST by Arthur Barrett - Building a commercial release of 2.5.04 will require updating our commercial
build machines (eg: acer64redhat) because 2.5.04 has different dependencies.
Some of these are minor and could probably be done with no effect on CVSNT
2.5.03 builds, but others are more significant.
autoconf (already updated acer64redhat)
libxml2 |
|
|
2008-05-03 20:48 AEST by Arthur Barrett - CVSNT 2.5.03 will compile with libxml 2.5.4 which is what was available with
Red Hat 9. However CVSNT 2.5.04 requires libxml 2.6.2x . Now Red Hat ES 4
came with 2.6.16 and RHEL 5 has 2.6.26. libxml2 2.6.26 in turn needs glibc
2.3.4 (and for some very odd reason one function needs glibc 2.4) wheras RH9
has 2.3.2. Now of course all sorts of things have to be upgraded if you are
upgrading to glibc 2.3.4 (which first came with RHEL4), eg: tzdata, nscd and
shadow-utils, which in turn need libselinux, libaudit and audit-libs...
The upshot of this is that the min redhat system requirement for 2.5.04 is
RHEL5.
Now in theory you could download the source package for libxml2 2.6.2x and
compile it on a different gcc/glibc - but whether that would work and the
implications are anyones guess. I've been at a bank customer in Sydney
recently and certainly there is NO WAY ON EARTH they would allow such a thing -
if the OS vendor does not support it it's just not on.
So this probably means that due to 2.5.04 using libxml2 2.6.2x that we are
restricted to very very very recent versions of the OS's, and in particular
RHEL5.
Assuming (though all of those need checking):
Solaris 10
SUSE 10
Mac OS 10.5
RHEL5
For HPUX I compiled libxml2-2.6.30 myself since no HP site has the libxml2
libraries at all though I now notice the porting centre has 11i v1, v2 and v3
packages for pa-risc and v2 and v3 packages for itanium (I've downloaded all
these to h:/downloads). Runtime dependencies listed are only gettext libiconv
zlib which suggests that it's been compiled with aCC:
http://hpux.cs.utah.edu/hppd/hpux/Gnome/libxml2-2.6.31/
|
|
|
2008-05-05 11:16 AEST by Arthur Barrett - libxml2 header versions installed on current machines (* = build machine):
* Solaris 9 sunny: 2.4.12
Solaris 10u4 sparc sune250: 2.6.23
* HPUX 11i v1 pa-risc melb0040: not installed
* HPUX 11i v2 itanium melb0030: 2.6.30 from source, 2.6.10 in /opt/wlm/
* Red Hat 9 acer64redhat: 2.5.4
* Red Hat ES 4 rhelv4: 2.6.16
* Debian acer64debian: 2.6.27
Debian debiancvs: 2.6.27
* suse sles 9 suse: not installed (library 2.6.7)
Tony's suggestions are:
1. import libxml into the source tree, like we used to with expat and do with
zlib, etc. I've been trying to move away from that since it means that cvsnt
needs to track security updates to the dependent library (and the tarball gets
much larger).
2. try to make the code compile on the old version of libxml, if it's
possible.. there's no list of functions for that version and I can imagine the
reaction if I asked for one on their mailing list - about the same one as if
someone asked on the cvsnt list for support for 2.0.38 :p
I think we just release 2.5.04 as it is.
For the commercial side I don't really intend upgrading beyond 2.5.03 until
next year at the earliest by which time this will be less of an issue - the
exception is 'multi site' installs - but we can just make the requirements for
that 'higher' and also support fees for those customers justifies the added
hardware investment in build servers.
A lot of 'free' users could be upset about the libxml2 requirement - I imagine
there are a LOT of them in corporates with RHES4 who are going to spit when
CVSNT wont compile and the RPM wont install due to failed dependencies that are
only available in RHES5.
Tony suggests that if this does pose a problem they just download the latest
RHES4 libxml2 RPM from xmlsoft.org or we offer to host one on cvsnt.org:
ftp://xmlsoft.org/libxml2/
I notice that the latest edition of Solaris 10 virtualisation supports
virtualised Solaris 8 and 9 servers under Solaris 10 (it's about time). This
definitely makes acquiring a machine from the Solaris hardware programme with
fast CPU and lots of RAM a higher priority - we'd need something more robust
than the e250 (2x400Mhz UltraSparc II CPUs and 2Gb RAM) to run it I think.
http://www.sun.com/software/solaris/containers/index.jsp
The Solaris 8 Containers software requires a SPARC system running Solaris 10
8/07 or later. The Solaris 9 Containers software requires a SPARC system
running Solaris 10 8/07 or later with patch #127111-01 or later revisions.
Documentation:
http://docs.sun.com/app/docs
Interestingly I never know Sun guarenteed binary compatibility:
http://www.sun.com/software/solaris/guarantee.jsp
I should probably investigate the HPUX virtual server environment (VSE)
virtualisation/virtual partitions some more as well:
http://docs.hp.com/en/vse.html
|
|
|
2008-05-05 17:08 AEST by Arthur Barrett - Wont 'configure' on mac os 10.3.7 due to missing automake 1.9:
Making all in libltdl
cd . && /bin/sh /Users/thoyle/cvs/cvsnt/libltdl/missing --run aclocal-1.9
/Users/thoyle/cvs/cvsnt/libltdl/missing: line 52: aclocal-1.9: command not found
WARNING: `aclocal-1.9' is missing on your system. You should only need it if
you modified `acinclude.m4' or `configure.ac'. You might want
to install the `Automake' and `Perl' packages. Grab them from
any GNU archive site.
cd . && /bin/sh /Users/thoyle/cvs/cvsnt/libltdl/missing --run automake-1.9 --foreign
/Users/thoyle/cvs/cvsnt/libltdl/missing: line 52: automake-1.9: command not found
WARNING: `automake-1.9' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
cd . && /bin/sh /Users/thoyle/cvs/cvsnt/libltdl/missing --run autoconf
autoconf: warning: both `configure.ac' and `configure.in' are present.
autoconf: warning: proceeding with `configure.ac'.
configure.ac:53: error: Autoconf version 2.58 or higher is required
aclocal.m4:446: AM_INIT_AUTOMAKE is expanded from...
configure.ac:53: the top level
autom4te: /usr/bin/gm4 failed with exit status: 1
make[2]: *** [configure] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
make complete...
|
|
|
2008-05-06 12:25 AEST by Arthur Barrett - Updated libxml2 header versions installed on current machines (* = build machine):
* Mac OS 10.3.7 PowerPC ti800: 2.5.4
* Mac OS 10.4.x Intel cremorneimac: 2.6.16
Mac OS 10.5.x Intel MacAir: 2.6.16
* Solaris 9 sunny: 2.4.12
Solaris 10u4 sparc sune250: 2.6.23
* HPUX 11i v1 pa-risc melb0040: not installed
* HPUX 11i v2 itanium melb0030: 2.6.30 from source, 2.6.10 in /opt/wlm/
* Red Hat 9 acer64redhat: 2.5.4
* Red Hat ES 4 rhelv4: 2.6.16
* Debian acer64debian: 2.6.27
Debian debiancvs: 2.6.27
* suse sles 9 suse: not installed (library 2.6.7)
Tony has said he is going to revisit the code and see if it is possible to redesign it in such a way that it
will compile with libxml2 2.6.1x (and higher), particularly since even the latest Mac OS X does not
support libxml2 2.6.2x.
Supporting libxml2 2.6.1x will still mean the end of cvsnt support for RH9/Mac10.3 etc, but that is not
as severe as the current situation which is basically RH5 only.
|
|
|
2008-05-08 13:02 AEST by Arthur Barrett - Tony has updated the cvsapi to allow building with earlier libxml2 libraries - however in his limited
testing he found it crashes often, so needs testing.
Build fails on Mac OS 10.3.7 - not due to the libxml2 but due to something with the makefiles in libltdl.
I had already re-generated these and re-committed to get rid of the datestamp problem from last time
- I was expecting that the make would now have nothing to do in this directory, but it seems to still
want to do stuff:
Making all in cvsapi/ufc-crypt
gcc-3.3 -D__DARWIN_OS__=7 -fPIC -DPIC -c -o crypt_util.o crypt_util.c
gcc-3.3 -D__DARWIN_OS__=7 -fPIC -DPIC -c -o ufccrypt.o ufccrypt.c
ar rc libufc.a crypt_util.o ufccrypt.o
Making all in libltdl
cd . && /bin/sh /Users/thoyle/cvs/cvsnt/libltdl/missing --run autoheader
autoheader: warning: `configure.ac' and `configure.in' both present.
at /usr/bin/autoheader line 113
autoheader: warning: proceeding with `configure.ac'.
at /usr/bin/autoheader line 113
aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of autoconf. If you want to use that,
you should regenerate the build system entirely.
aclocal.m4:17: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
autoheader: /usr/bin/autom4te failed with exit status: 1
make[2]: *** [config-h.in] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Building on Mac OS 10.4.x seems to go OK - no testing done yet though.
|
|
|
2008-05-11 21:42 AEST by Arthur Barrett - Testing with Mac OS X 10.5 shows major errors:
Unable to evaluate xpath expression 'file[cvs:filename(@name,$name)]/acl'
N cvsnt/zlib/win32/zlib.def
XML error at line 0: Invalid or inclomplete context
Unable to evaluate xpath expression 'file[cvs:filename(@name,$name)]/acl'
N cvsnt/zlib/win32/zlib.vcproj
XML error at line 0: Invalid or inclomplete context
Unable to evaluate xpath expression 'file[cvs:filename(@name,$name)]/acl'
N cvsnt/zlib/win32/zlib1.rc
No conflicts created by this import
|
|
|
2008-05-12 12:25 AEST by Arthur Barrett - Committing a change when ACL exists and aclmode=normal also gives errors (still Mac OS 10.5):
cvs commit: Examining zlib/win32
XML error at line 0: Invalid or inclomplete context
Unable to evaluate xpath expression 'file[cvs:filename(@name,$name)]/acl'
XML error at line 0: Invalid or inclomplete context
Unable to evaluate xpath expression 'file[cvs:filename(@name,$name)]/acl'
Checking in build.h;
/testrepo/cvsnt/build.h,v <-- build.h
new revision: 1.2; previous revision: 1.1
done
MacAir:cvsnt-here abarrett$ cat /Users/abarrett/testrepo/cvsnt/*.xml
cat: /Users/abarrett/testrepo/cvsnt/*.xml: No such file or directory
MacAir:cvsnt-here abarrett$ cat /Users/abarrett/testrepo/cvsnt/CVS/*.xml
<?xml version="1.0"?>
<fileattr>
<directory>
<acl user="abarrett">
<modified_by>abarrett</modified_by>
<modified_date>2008.05.12.02.20.43</modified_date>
<all/>
</acl>
</directory>
</fileattr>
|
|
|
2008-07-02 12:07 AEST by Arthur Barrett - Now the 'local' libxml2 has a dependency with pthread:
../diff/libdiff.a(diff3.o)(.text+0x182c): In function `read_diff':
/usr/src/redhat/BUILD/cvsnt-2.5.04.3111/diff/diff3.c:1401: the use of `mktemp'
is dangerous, better use `mkstemp'
../cvsapi/.libs/libcvsapi.so: undefined reference to `pthread_getspecific'
../cvsapi/.libs/libcvsapi.so: undefined reference to `pthread_once'
../cvsapi/.libs/libcvsapi.so: undefined reference to `pthread_key_create'
../cvsapi/.libs/libcvsapi.so: undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
Try and accomodate this in configure:
Index: configure.in
===================================================================
RCS file: /cvs/cvsnt/configure.in,v
retrieving revision 1.41.2.196
diff -c -r1.41.2.196 configure.in
*** configure.in 26 Jun 2008 02:22:42 -0000 1.41.2.196
--- configure.in 2 Jul 2008 03:02:25 -0000
***************
*** 399,404 ****
--- 399,407 ----
if test x$ac_cv_have_libxml != xyes; then
AC_CONFIG_SUBDIRS(libxml)
CPPFLAGS="$CPPFLAGS -I\$(top_srcdir)/libxml/include"
+ # This is dependent on pthreads so if using internal libxml2 then pthreads
must exist
+ LIBS="$LIBS $PTHREAD_LIBS"
+ CPPFLAGS="$CPPFLAGS $PTHREAD_CPPFLAGS"
else
CPPFLAGS="$CPPFLAGS $LIBXML_CPPFLAGS"
fi
|
|
|
2008-07-11 16:11 AEST by Arthur Barrett - Created an attachment (id=1314)
Patch to libxml2
I am having a LOT of troubles getting libxml2 statically linking with HPUX.
Basically the linker bombs because there is no xmlFree symbol in cvsapi...
I've modified the windows project to also statically link it (primarily for
debugging, but I'll probably leave it that way for 2.5.04 and make it dynamic
again in 2.5.05).
There seem to be two problems:
1) if libxml2 threads are enabled then xmlFree() is some weird thread based
function or something
2) if threads are not enabled then xmlFree() is just #defined to free() which
causes HPUX grief
To get around this:
1) I've changed the configure default for libxml2 in cvsnt to --with-threads=no
2) I've written a 'wrapper' function for free() in xmlmemory.c
|
|
|
2008-07-14 18:06 AEST by Arthur Barrett - OK the problems I've been having with HPUX appear not to be HPUX problems, but
can be sumarised as follows:
1) there were some bugs in the configure.in file (fixed)
2) the comptest for libxml to determine the library version was done in "C"
however HPUX requires it be in "C++" (fixed)
3) libtool cannot link a static library with a shared library
see this post
http://osdir.com/ml/gnu.libtool.general/2003-02/msg00150.html
4) libtool silently fails to link correctly unless all shared and static
libraries have been compiled "position independant" ie: -fPIC
Finally: HPUX does have |