About building frysk on ppc64

[Wu Zhou <woodzltc at cn dot ibm dot com>]

To build frysk successfully on ppc64, some extra works are needed  
right now.  Some of them is not that bothering: after machine is  
setup, doing once is ok; others are a little bothering, everytime we  
check out the latest code from the cvs repository, we need to do some  
patching to make it build on ppc64.  So we want to list them here to  
see if we can have any remedy for them.

1. There are some missing 64-bit packages.

Most of them are 64-bit libraries, including libgcj-4.1.1-3.ppc64.rpm,  
binutils-2.17.50.0.2-4.ppc64.rpm, libgtk-java-2.8.5-0.ppc64.rpm,  
cairo-java-1.0.4-0.ppc64.rpm, glib-java-0.2.5-0.ppc64.rpm,  
libglade-java-2.12.4-0.ppc64.rpm, libvte-java-0.12.0-0.ppc64.rpm,  
libgnome-java-2.12.3-0.ppc64.rpm,
libgconf-java-2.12.1.0.20060301.rh1-1.ppc64.rpm.  Bug 2905 was opened  
for this: http://sourceware.org/bugzilla/show_bug.cgi?id=2905

On PPC64, 64-bit bin-utils package is also needed.  bug 2906 was  
opened to track this:  
http://sourceware.org/bugzilla/show_bug.cgi?id=2906

We are wishing that they can be fixed in a later Fedora update and  
RHEL release. But it is not that bothering right now.  After  
downloading these packages and installing them, we don't be bited by  
them if there is no need to re-install or update system.


2. Some routines in libopcode for ppc64 have dependences on libbfd and  
libiberty.  So to build these part of code, two extra options (-lbfd  
and -liberty) are needed. Yao Qi ever submitted a patch and Rick  
Moseley checked it in and removed it out a while later. (please refer  
to the mail thread:  
http://sources.redhat.com/ml/frysk/2006-q2/msg00098.html)

According to the changelog, a long-term decision is needed to maken  
before we know how to proceed.  Can we know what is the status of this  
decision?  If this decision can't be maken yet, could we have a work  
around first.

Our work around is like this: if the configure script finds that the  
system is ppc64, use "-lopcodes -lbfd -liberty"; if not, nothing is  
changed.  Is this work around ok?  If it is, we can submit a patch to  
handle this.

3. The current libunwind library doesn't support ppc64 platform (we  
are very happy to help in this field. :-).  The current frysk  
configuration can also detect if the target support libunwind or not.   
But this information is not transfered to libunwind's java binding.   
So frysk will fail to build in the phase of handling libunwind's java  
binding.  We have to remove all libunwind related code to make it  
build ok.  This is bothering indeed, because we have to do that every  
time we check out the latest cvs source.

So is there any chances this get improved.  In our opinion, the value  
of "use_libunwind" can be transfer to the binding code as a macro or  
similar thing, if it equals no, we don't do any binding at this time;  
if it is "yes", we do the binding.  Is this feasible and acceptable?   
If it is, we'd like to submit some code to handle this.


Any comments are highly appreciated.

Regards
- Wu Zhou