You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xalan.apache.org by "Bjoern A. Zeeb" <bz...@lists.zabbadoz.net> on 2003/06/24 19:36:31 UTC
FreeBSD port - please test
Hi,
on http://sources.zabbadoz.net/freebsd/ports/experimental/
you will find an up-to-date xerces-c2 2.3 port and and Xalan-c 1.5
port (work in progress).
http://sources.zabbadoz.net/freebsd/ports/experimental/xerces-c2-2.3-experimental.tgz
http://sources.zabbadoz.net/freebsd/ports/experimental/xalan-1.5-experimental.tgz
While xerces-c2 should be fully tested and OK the xalan port is rarely
tested AND only with libiconv on i386 yet.
please extract both and simply do a make in xerces-c2, su && make
install and afterwards do the same for the xalan port (if you don't
know how to build ports please have a look at the ports-handbook).
I tested Xalan on 4.7-STABLE and 5.1R and it worked fine.
Any feedback ist welcome.
PS: the xalan-tarball includes a patch-aa which includes a make
install target and a somewhat improved build framework for Xalan.
Unluckily the diff is against 1.5 release and not against CVS but
I am pretty sure I broke OS390 anyway ;-)
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: FreeBSD port - please test
Posted by "Bjoern A. Zeeb" <bz...@lists.zabbadoz.net>.
On Mon, 7 Jul 2003, Bjoern A. Zeeb wrote:
Hi,
> > > BTW: do you have own icu-2 / xerces-c2 ports or do you use the once I
> > > submitted ?
> >
> > We used our own because we needed a version that didn't link with
> > libc_r.so (i.e., no pthread) because on FreeBSD 4.x, libc and libc_r
> > apparently do not work well with each other -- it would cause random
> > crashes. That problem is supposed to be fixed on 5.x I heard.
> >
> > But for 4.x, perhaps we should create a separate port for thread-based
> > and non-thread-based of ICU, xerces-c2 and xalan-c?
>
> The ports all have a NO_THREADS option you can set when rebuilding.
> There has been one issue with either the xerces or the xalan port
> noted by Berin Lautenbach and is fixed at least in my local versions
> now; got linked against both libc and libc_r.
Ok, I have verified that my Xalan port still builds with either iconv
and icu2 and uploaded a new tarball I am going to submit to FreeBSD
gnats once I have some positive reports.
It should automagically detect if xerces-c2 got linked with iconv or
icu.
Up-to-date port sources (not yet commited to freebsd ports tree) for
the whole chain can be found on
http://sources.zabbadoz.net/freebsd/ports/
(including references to the PRs):
ICU 2.6:
http://sources.zabbadoz.net/freebsd/ports/icu2-2.4_1-2.6-20030615-01.tbz
Xerces-c2 2.3.0:
http://sources.zabbadoz.net/freebsd/ports/xerces-c2-2.2.0-2.3.0-20030709-01.tbz
Xalan-1.5:
http://sources.zabbadoz.net/freebsd/ports/xalan-c-1.5-20030710-01.tbz
The Xalan build framework update[1] is still pending.
I think it might take another few weeks for it to be commited so I
am no longer going to wait with the port but simply include
these changes for now.
[1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13238
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: FreeBSD port - please test
Posted by "Bjoern A. Zeeb" <bz...@lists.zabbadoz.net>.
On Mon, 7 Jul 2003, David Yan wrote:
Hi,
ok we are getting offtopic again but if it helps ...
> > BTW: do you have own icu-2 / xerces-c2 ports or do you use the once I
> > submitted ?
>
> We used our own because we needed a version that didn't link with
> libc_r.so (i.e., no pthread) because on FreeBSD 4.x, libc and libc_r
> apparently do not work well with each other -- it would cause random
> crashes. That problem is supposed to be fixed on 5.x I heard.
>
> But for 4.x, perhaps we should create a separate port for thread-based
> and non-thread-based of ICU, xerces-c2 and xalan-c?
The ports all have a NO_THREADS option you can set when rebuilding.
There has been one issue with either the xerces or the xalan port
noted by Berin Lautenbach and is fixed at least in my local versions
now; got linked against both libc and libc_r.
Berin can you have a look at the build framework please so I might
release some final freebsd ports and find someone to commit them so
they get in the ports tree ?
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: FreeBSD port - please test
Posted by David Yan <da...@yahoo-inc.com>.
> I do have some changes since the last tarballs[1] but I am also
> successfully running Xalan on 4.{6,7,8}-STABLE and 5.x now with either
> iconv or icu[2] (autodetected depended on what xerces-c2[3] has been
> built with).
>
> [1] still waiting for the build framework commit before uploading them
> and adding to the open PR @ freebsd.org
> [2] using the port from the PR for icu 2.6 update I submitted
> [3] version 2.3 port; commit still pending too I think
>
> Perhaps we can merge the ports ?
The only changes we made is in the Makefiles/config scripts and they
are just simple changes. We didn't change the code at all. We could
just use yours.
> BTW: do you have own icu-2 / xerces-c2 ports or do you use the once I
> submitted ?
We used our own because we needed a version that didn't link with
libc_r.so (i.e., no pthread) because on FreeBSD 4.x, libc and libc_r
apparently do not work well with each other -- it would cause random
crashes. That problem is supposed to be fixed on 5.x I heard.
But for 4.x, perhaps we should create a separate port for thread-based
and non-thread-based of ICU, xerces-c2 and xalan-c?
David
Re: FreeBSD port - please test
Posted by "Bjoern A. Zeeb" <bz...@lists.zabbadoz.net>.
On Mon, 7 Jul 2003, David Yan wrote:
Hi,
> We at Yahoo! have Xalan-C 1.5 working on FreeBSD 4.8 with Xerces-C 2.2
> and ICU 2.6. We are preparing a port now. Please let me know if
> you're interested in the details.
So we will have two ports for the same ? :((
I do have some changes since the last tarballs[1] but I am also
successfully running Xalan on 4.{6,7,8}-STABLE and 5.x now with either
iconv or icu[2] (autodetected depended on what xerces-c2[3] has been
built with).
[1] still waiting for the build framework commit before uploading them
and adding to the open PR @ freebsd.org
[2] using the port from the PR for icu 2.6 update I submitted
[3] version 2.3 port; commit still pending too I think
Perhaps we can merge the ports ?
BTW: do you have own icu-2 / xerces-c2 ports or do you use the once I
submitted ?
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: FreeBSD port - please test
Posted by David Yan <da...@yahoo-inc.com>.
Hi all,
We at Yahoo! have Xalan-C 1.5 working on FreeBSD 4.8 with Xerces-C 2.2
and ICU 2.6. We are preparing a port now. Please let me know if
you're interested in the details.
David
Bjoern A. Zeeb writes at 17:36 on 6/24/2003:
> Hi,
>
> on http://sources.zabbadoz.net/freebsd/ports/experimental/
>
> you will find an up-to-date xerces-c2 2.3 port and and Xalan-c 1.5
> port (work in progress).
>
> http://sources.zabbadoz.net/freebsd/ports/experimental/xerces-c2-2.3-experimental.tgz
> http://sources.zabbadoz.net/freebsd/ports/experimental/xalan-1.5-experimental.tgz
>
> While xerces-c2 should be fully tested and OK the xalan port is rarely
> tested AND only with libiconv on i386 yet.
>
> please extract both and simply do a make in xerces-c2, su && make
> install and afterwards do the same for the xalan port (if you don't
> know how to build ports please have a look at the ports-handbook).
>
> I tested Xalan on 4.7-STABLE and 5.1R and it worked fine.
>
> Any feedback ist welcome.
>
>
> PS: the xalan-tarball includes a patch-aa which includes a make
> install target and a somewhat improved build framework for Xalan.
> Unluckily the diff is against 1.5 release and not against CVS but
> I am pretty sure I broke OS390 anyway ;-)
>
> --
> Greetings
>
> Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
> 56 69 73 69 74 http://www.zabbadoz.net/
>
Re: FreeBSD port - please test
Posted by "Bjoern A. Zeeb" <bz...@lists.zabbadoz.net>.
On Wed, 25 Jun 2003, Berin Lautenbach wrote:
Hi,
> WooHoo! Works like a charm. testXPath now runs on my 4.8-RELEASE box,
> so very happy.
:-))
> What I might do (if you have no objections), is incorporate the minimal
> amount of changes into the current makefiles to get Freebsd to compile
> and run properly.
That is what I first did - I hope I still have these patches. My plan
was to merge my patch and current CVS, sent it back via bugzilla and
get it in and tested as fast as possible for as much platforms a possble.
Then get the diff back from CVS before sending pr to FreeBSD gnats.
OS390 is a special problem I think because they don't seem to use gcc(?)
and have the .x moves and I don't have a plan what this is for.
I think it might be an equivalent to .so files.
The problem was the same as with xerces (library naming on elf system
was broken). Also see my bug report for xerces-c:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13992
> I might leave the install piece out for now, although I think it's an
no I will not do that ;-) I don't want to copy all this to the
Makefile of the port. This is the wrong place.
[more see above]
> important piece - but if there is a risk of breaking OS390 I'd like to
> take things slowly.
I am pretty sure the maintainers from IBM will get this fixed (if
broken) within minutes ;-)
> I might also slightly modify the configure test you have built in to
> actually run a piece of code to test mbstowcs, as this is also a problem
> on NetBSD so it would be good to have a generic test.
well this is no problem at all. What arch maintainers will have todo
is add the ${WCSTOMBS} (formerly known as ${PCO}; already changed that
locally) to their PLATFORM_COMPILE_OPTIONS. One can also do that for
netbsd (if one includes the build options to Makefile.in) and have a
more generic test like ... in configure.in:
--- untested ---
dnl check if mbstowcs is available and can correctly count only
AC_HEADER_STDC
AC_CHECK_FUNCS([mbstowcs],,,)
if test x"$ac_cv_func_mbstowcs" = x"no"; then
WCSTOMBS="-DXALAN_USE_XERCES_LOCAL_CODEPAGE_TRANSCODERS"
else
AC_MSG_CHECKING(if mbstowcs can count only)
AC_TRY_RUN([
#if STDC_HEADERS
#include <stdlib.h>
#endif
int main(int argc, char *argv[])
{
wchar_t in[5] = { 0x74, 0x65, 0x73, 0x74, 0x00 };
if (wcstombs(0, in, 0) == -1) {
exit(1);
}
exit(0);
}], [AC_MSG_RESULT(yes)],
[WCSTOMBS="-DXALAN_USE_XERCES_LOCAL_CODEPAGE_TRANSCODERS";
AC_MSG_RESULT(no)])
fi
--- /untested ---
> The only problem is that this might break the port that you have done,
> but hopefully we can keep the breakage to an easily defined subset.
no breakage allowed ;-)) Well I have found another Problem on a
4.6-STABLE box. pkg_info output has changed a bit and the direcotry from
where the port had been built was not stored. So I also added defaults
for this case that we find libiconv/icu there too.
I will now start testing the icu chain and if it works release a new
tarball and add the configure/install patch to bugzilla.
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: build framework changes [was: FreeBSD port - please test]
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Bjoern,
Definitely a +1 from here! I didn't get a chance to look at it this
weekend, but I did see your bugzilla attachment.
Will try to incorporate in the near future :>.
Cheers,
Berin
Bjoern A. Zeeb wrote:
> On Wed, 25 Jun 2003, Berin Lautenbach wrote:
>
> Hi,
>
>
>>What I might do (if you have no objections), is incorporate the minimal
>>amount of changes into the current makefiles to get Freebsd to compile
>>and run properly.
>
> [1]
>
>
>>I might leave the install piece out for now, although I think it's an
>>important piece - but if there is a risk of breaking OS390 I'd like to
>>take things slowly.
>
> [2]
>
>
>>I might also slightly modify the configure test you have built in to
>>actually run a piece of code to test mbstowcs, as this is also a problem
>>on NetBSD so it would be good to have a generic test.
>
> [3]
>
>
>>The only problem is that this might break the port that you have done,
>>but hopefully we can keep the breakage to an easily defined subset.
>
> [4]
>
> coming back to this all.
>
> As you might have seen I added the diff to
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13238
>
> I am going to start with [2]:
> As stated at least in the PR the problem was that on ELF systems
> shared libraries have to have a "correct naming". This is the major
> version at the end is important. Up to this the library had been
> called something like libxalan-c1_5_0.so. This will never be
> recognized as a shared library. The correct naming is libxalan-c.so.${major}
> As one may also have a minor common proactice seems to be to call it
> libxalan-c.so.${major}.${minor} and have symlinks for .so.${major} and
> .so. This is the important change (that might break OS390).
> That is why I renamed THISLIB and introdocued LIB. For OS390
> everything should be the same. The only difference left might be in
> this section I think.
>
> --- cut ---
> -lib: prepare compile $(THISLIB)$(VER)$(SHLIBSUFFIX)
> +lib: prepare compile $(THISLIB)
>
> -$(THISLIB)$(VER)$(SHLIBSUFFIX): $(ALL_OBJECTS)
> +$(THISLIB): $(ALL_OBJECTS)
> $(MAKE_SHARED) $(PLATFORM_LIBRARIES) $(EXTRA_LINK_OPTIONS) $(ALLLIBS) $^ -o $@
> --- cut ---
>
> It might work pretty well as I tired to keep the naming of the library
> on OS390 the same it has been up to this. The only thing I do not
> understand - because of lack of knowledge - is that .x thing ?
> Perhaps someone can tell me and simply test it ?
>
> The install target itself could be left out and has no influence on this
> but is depended on the change.
>
>
> [3]:
> I posted this one. It is included in the bugzilla report as is
> a NetBSD section which I cannot test it because I do not have access
> to a netbsd system at the moment. From what I had seen in xerces-c it
> should simply work.
>
>
> [4] and [1]:
> up to this we should be (allmost) fine. The problem from my side seems that
> I would need some people to +1 for it ;-)
> Perhaps we can find an ideal solution for both sides to get - at least -
> parts of this in now and and others later. The problem will be that
> further changes to the build framework might break the patch and one would
> need to redo a lot of this to check that it still fits.
> The configure.in and runConfigure changes should be no problem to
> commit as they won't break anything I think.
> I would also be willing to change the Makefile.in to minimal changes
> need to compile on FreeBSD if this would really help but it would be
> no good for most of the users I think.
>
>
Re: build framework changes [was: FreeBSD port - please test]
Posted by June Ng <ju...@ca.ibm.com>.
The *.x thing is something that is unique to OS390. It's the extension
for the definiton side deck. The definition side deck is a flat text file
that contains a list of symbols and the dll they can be found in. It is
created when you build a DLL. The *.x file is treated like an object file
when linking your main application and is used for symbol resolution.
Hope that helps.
Cheers,
June K. Ng
XSLT Development
IBM Toronto Laboratory
Phone: 905-413-3422 T/L: 969-3422
Email: june@ca.ibm.com
"Bjoern A. Zeeb" <bz...@lists.zabbadoz.net>
06/29/2003 01:47 PM
To: Berin Lautenbach <be...@ozemail.com.au>
cc: Xalan C Users <xa...@xml.apache.org>
Subject: Re: build framework changes [was: FreeBSD port -
please test]
On Wed, 25 Jun 2003, Berin Lautenbach wrote:
Hi,
> What I might do (if you have no objections), is incorporate the minimal
> amount of changes into the current makefiles to get Freebsd to compile
> and run properly.
[1]
> I might leave the install piece out for now, although I think it's an
> important piece - but if there is a risk of breaking OS390 I'd like to
> take things slowly.
[2]
> I might also slightly modify the configure test you have built in to
> actually run a piece of code to test mbstowcs, as this is also a problem
> on NetBSD so it would be good to have a generic test.
[3]
> The only problem is that this might break the port that you have done,
> but hopefully we can keep the breakage to an easily defined subset.
[4]
coming back to this all.
As you might have seen I added the diff to
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13238
I am going to start with [2]:
As stated at least in the PR the problem was that on ELF systems
shared libraries have to have a "correct naming". This is the major
version at the end is important. Up to this the library had been
called something like libxalan-c1_5_0.so. This will never be
recognized as a shared library. The correct naming is
libxalan-c.so.${major}
As one may also have a minor common proactice seems to be to call it
libxalan-c.so.${major}.${minor} and have symlinks for .so.${major} and
.so. This is the important change (that might break OS390).
That is why I renamed THISLIB and introdocued LIB. For OS390
everything should be the same. The only difference left might be in
this section I think.
--- cut ---
-lib: prepare compile $(THISLIB)$(VER)$(SHLIBSUFFIX)
+lib: prepare compile $(THISLIB)
-$(THISLIB)$(VER)$(SHLIBSUFFIX): $(ALL_OBJECTS)
+$(THISLIB): $(ALL_OBJECTS)
$(MAKE_SHARED) $(PLATFORM_LIBRARIES)
$(EXTRA_LINK_OPTIONS) $(ALLLIBS) $^ -o $@
--- cut ---
It might work pretty well as I tired to keep the naming of the library
on OS390 the same it has been up to this. The only thing I do not
understand - because of lack of knowledge - is that .x thing ?
Perhaps someone can tell me and simply test it ?
The install target itself could be left out and has no influence on this
but is depended on the change.
[3]:
I posted this one. It is included in the bugzilla report as is
a NetBSD section which I cannot test it because I do not have access
to a netbsd system at the moment. From what I had seen in xerces-c it
should simply work.
[4] and [1]:
up to this we should be (allmost) fine. The problem from my side seems
that
I would need some people to +1 for it ;-)
Perhaps we can find an ideal solution for both sides to get - at least -
parts of this in now and and others later. The problem will be that
further changes to the build framework might break the patch and one would
need to redo a lot of this to check that it still fits.
The configure.in and runConfigure changes should be no problem to
commit as they won't break anything I think.
I would also be willing to change the Makefile.in to minimal changes
need to compile on FreeBSD if this would really help but it would be
no good for most of the users I think.
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74
http://www.zabbadoz.net/
Re: build framework changes [was: FreeBSD port - please test]
Posted by "Bjoern A. Zeeb" <bz...@lists.zabbadoz.net>.
On Wed, 25 Jun 2003, Berin Lautenbach wrote:
Hi,
> What I might do (if you have no objections), is incorporate the minimal
> amount of changes into the current makefiles to get Freebsd to compile
> and run properly.
[1]
> I might leave the install piece out for now, although I think it's an
> important piece - but if there is a risk of breaking OS390 I'd like to
> take things slowly.
[2]
> I might also slightly modify the configure test you have built in to
> actually run a piece of code to test mbstowcs, as this is also a problem
> on NetBSD so it would be good to have a generic test.
[3]
> The only problem is that this might break the port that you have done,
> but hopefully we can keep the breakage to an easily defined subset.
[4]
coming back to this all.
As you might have seen I added the diff to
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13238
I am going to start with [2]:
As stated at least in the PR the problem was that on ELF systems
shared libraries have to have a "correct naming". This is the major
version at the end is important. Up to this the library had been
called something like libxalan-c1_5_0.so. This will never be
recognized as a shared library. The correct naming is libxalan-c.so.${major}
As one may also have a minor common proactice seems to be to call it
libxalan-c.so.${major}.${minor} and have symlinks for .so.${major} and
.so. This is the important change (that might break OS390).
That is why I renamed THISLIB and introdocued LIB. For OS390
everything should be the same. The only difference left might be in
this section I think.
--- cut ---
-lib: prepare compile $(THISLIB)$(VER)$(SHLIBSUFFIX)
+lib: prepare compile $(THISLIB)
-$(THISLIB)$(VER)$(SHLIBSUFFIX): $(ALL_OBJECTS)
+$(THISLIB): $(ALL_OBJECTS)
$(MAKE_SHARED) $(PLATFORM_LIBRARIES) $(EXTRA_LINK_OPTIONS) $(ALLLIBS) $^ -o $@
--- cut ---
It might work pretty well as I tired to keep the naming of the library
on OS390 the same it has been up to this. The only thing I do not
understand - because of lack of knowledge - is that .x thing ?
Perhaps someone can tell me and simply test it ?
The install target itself could be left out and has no influence on this
but is depended on the change.
[3]:
I posted this one. It is included in the bugzilla report as is
a NetBSD section which I cannot test it because I do not have access
to a netbsd system at the moment. From what I had seen in xerces-c it
should simply work.
[4] and [1]:
up to this we should be (allmost) fine. The problem from my side seems that
I would need some people to +1 for it ;-)
Perhaps we can find an ideal solution for both sides to get - at least -
parts of this in now and and others later. The problem will be that
further changes to the build framework might break the patch and one would
need to redo a lot of this to check that it still fits.
The configure.in and runConfigure changes should be no problem to
commit as they won't break anything I think.
I would also be willing to change the Makefile.in to minimal changes
need to compile on FreeBSD if this would really help but it would be
no good for most of the users I think.
--
Greetings
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: FreeBSD port - please test
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Bjoern,
WooHoo! Works like a charm. testXPath now runs on my 4.8-RELEASE box,
so very happy.
What I might do (if you have no objections), is incorporate the minimal
amount of changes into the current makefiles to get Freebsd to compile
and run properly.
I might leave the install piece out for now, although I think it's an
important piece - but if there is a risk of breaking OS390 I'd like to
take things slowly.
I might also slightly modify the configure test you have built in to
actually run a piece of code to test mbstowcs, as this is also a problem
on NetBSD so it would be good to have a generic test.
The only problem is that this might break the port that you have done,
but hopefully we can keep the breakage to an easily defined subset.
Cheers (and thanks!),
Berin
Bjoern A. Zeeb wrote:
> Hi,
>
> on http://sources.zabbadoz.net/freebsd/ports/experimental/
>
> you will find an up-to-date xerces-c2 2.3 port and and Xalan-c 1.5
> port (work in progress).
>
> http://sources.zabbadoz.net/freebsd/ports/experimental/xerces-c2-2.3-experimental.tgz
> http://sources.zabbadoz.net/freebsd/ports/experimental/xalan-1.5-experimental.tgz
>
> While xerces-c2 should be fully tested and OK the xalan port is rarely
> tested AND only with libiconv on i386 yet.
>
> please extract both and simply do a make in xerces-c2, su && make
> install and afterwards do the same for the xalan port (if you don't
> know how to build ports please have a look at the ports-handbook).
>
> I tested Xalan on 4.7-STABLE and 5.1R and it worked fine.
>
> Any feedback ist welcome.
>
>
> PS: the xalan-tarball includes a patch-aa which includes a make
> install target and a somewhat improved build framework for Xalan.
> Unluckily the diff is against 1.5 release and not against CVS but
> I am pretty sure I broke OS390 anyway ;-)
>