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/29 19:47:41 UTC
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 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/