Bug 185544

Summary: 64-bits development libraries are needed to build frysk on PPC64
Product: [Fedora] Fedora Reporter: wzhou <zhouwu>
Component: libxml2Assignee: Daniel Veillard <veillard>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: cagney, ezannoni
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-06-08 13:46:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description wzhou 2006-03-15 17:47:51 UTC
Description of problem:

PPC64 is a bi-arch platform.  We need to build frysk as 64-bits binary to handle
both 64-bits and 32-bits application.

But it seems that there are only 32-bits development libraries in PPC64
platform.  This will impact the building of frysk in 64-bits mode.  It might
also impact other development projects too.

For frysk, the following 64-bits development libraries is needed:

(under /usr/lib64)
./libatk-1.0.so -> libatk-1.0.so.0.800.0
./libexpat.so -> libexpat.so.0.5.0
./libfontconfig.so -> libfontconfig.so.1.0.4
./libfreetype.so -> libfreetype.so.6.3.7
./libglib-2.0.so -> libglib-2.0.so.0.400.7
./libgmodule-2.0.so -> libgmodule-2.0.so.0.400.7
./libgobject-2.0.so -> libgobject-2.0.so.0.400.7
./libjpeg.so -> libjpeg.so.62.0.0
./libpng12.so -> libpng12.so.0.1.2.7
./libtiff.so -> libtiff.so.3.6
./libvte.so -> libvte.so.4.4.0
./libxml2.so -> libxml2.so.2.6.16

Their pkgconfig description files are also needed in /usr/lib64/pkgconfig.

I had to create them by hand to make the building continue.

Version-Release number of selected component (if applicable):

How reproducible:

always.

Steps to Reproduce:
1. search in the directory /usr/lib, you will find these libraries;
2. search in the directory /usr/lib64, you won't find these libraries;
3.
  
Actual results:


Expected results:

These libraries is in /usr/lib64, their pakcage config files is in
/usr/lib64/pkfconfig.

Comment 1 Daniel Veillard 2006-03-15 22:24:13 UTC
> ./libxml2.so -> libxml2.so.2.6.16 ????
Libxml2 in FC5t3 is 2.6.23, certainly not 2.6.16 !

> search in the directory /usr/lib64, you won't find these libraries;
I don't have ppc64 but on x86_64 
[root@localhost ~]# ls -l /usr/lib64/libxml2.so
lrwxrwxrwx 1 root root 17 Mar 15 15:20 /usr/lib64/libxml2.so -> libxml2.so.2.6.23

> This will impact the building of frysk in 64-bits mode
Heck libxml2 compiles on MVS ! It has compiled on Linux 64bits "forever",
I don't understand the problem, I don't see anything specific to ppc or
64 bits in the spec file.

rpm -qilp libxml2-2.6.23-1.2.ppc64.rpm  | grep lib64
warning: libxml2-2.6.23-1.2.ppc64.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2
/usr/lib64/libxml2.so.2
/usr/lib64/libxml2.so.2.6.23

  the package has the files it should in /usr/lib64.
At this point this report sounds bogus to me, I don't know how you ended
up with the wrong libs installed...

Daniel


Comment 2 wzhou 2006-03-16 02:29:39 UTC
Hi Daniel,

Really sorry for reporting bogus information here.  Yesterday evening, I am in 
such a hurry that I simply copy and paste these information here.  They are 
for RHEL4 U3 instead.

OK. let me re-describe the problem here, wishing that it can help to clarify 
the problem.

Just as you said, libxml2 for in FC5 (I am using FC5 test2) is 2.6.23, here is 
the files on PPC64:

[root@plinuxt18 ~]# ls -l /usr/lib/libxml2.*
-rw-r--r-- 1 root root 1839088 Jan  5 23:59 /usr/lib/libxml2.a
lrwxrwxrwx 1 root root      17 Feb 19 16:04 /usr/lib/libxml2.so -> 
libxml2.so.2.6.23
lrwxrwxrwx 1 root root      17 Feb 19 15:55 /usr/lib/libxml2.so.2 -> 
libxml2.so.2.6.23
-rwxr-xr-x 1 root root 1401684 Jan  5 23:59 /usr/lib/libxml2.so.2.6.23

[root@plinuxt18 ~]# ls -l /usr/lib64/libxml2.*
lrwxrwxrwx 1 root root      17 Feb 19 15:55 /usr/lib64/libxml2.so.2 -> 
libxml2.so.2.6.23
-rwxr-xr-x 1 root root 1829944 Jan  6 00:00 /usr/lib64/libxml2.so.2.6.23

You can see from above, there is no link in /usr/lib64 from libxml2.so 
to /usr/lib64/libxml2.so.2.6.23; In /usr/lib64/pkgconfig, there is no libxml-
2.0.pc either. 

Seeing that, I am guess the problem does not lie in the compiling or building 
phase, but in the packaging phase instead.

[root@plinuxt18 ~]# rpm -qa --queryformat="%{NAME}-%{ARCH}-%{VERSION}\n" |grep 
libxml2
libxml2-ppc64-2.6.23
libxml2-devel-ppc-2.6.23
libxml2-python-ppc-2.6.23
libxml2-ppc-2.6.23

You can see that there is no libxml2-devel for ppc64.  I guess this is the 
problem, if only we can provide a libxml2-devel-2.6.23-1.2.ppc64.rpm, that 
will ok I believe.

What is your thought on this?  

Thanks.

Comment 3 Daniel Veillard 2006-03-16 10:13:22 UTC
> You can see that there is no libxml2-devel for ppc64

 That doesn't match what I see internally
dist/4E/libxml2/2.6.16-6/ppc64 -> ls
libxml2-2.6.16-6.ppc64.rpm            libxml2-devel-2.6.16-6.ppc64.rpm
libxml2-debuginfo-2.6.16-6.ppc64.rpm  libxml2-python-2.6.16-6.ppc64.rpm
dist/4E/libxml2/2.6.16-6/ppc64 -> rpm -qilp libxml2-devel-2.6.16-6.ppc64.rpm |
grep pkgconfig
/usr/lib64/pkgconfig/libxml-2.0.pc
dist/4E/libxml2/2.6.16-6/ppc64 ->

   So the libxml2-devel-2.6.23-1.2.ppc64.rpm has been built. I don't see them
on Red Hat Network, I have no idea why but apparently all devel packages
for ppc64 are 32 bits only. I assume it was a distro policy to do so. Ask
your Red hat contact about this, there is no way I am gonna push out packages
against what seems a distro policy, you must contact your support person.
In practice, you can grab the src.rpm and rebuild it, but of course that's
not standard and may void your support if you install them.
   Technically I don't see this as a bug, code wise and package wise libxml2
is fine, you won't get a resolution to this via bugzilla. Again talk to your
contact, I don't feel there is anything I can do...

Daniel


Comment 4 Andrew Cagney 2006-03-16 15:49:39 UTC
Repoening, if the bug isn't in libxml, please re-assign to relevant responsibility.

Comment 6 Daniel Veillard 2006-06-08 13:46:33 UTC
No idea what's happened, no news, closing as WONTFIX,

Daniel