libxml2 not in 64 bit

[Michiel Eghuizen]

Hello,

I was trying to export an iSCSI target, when I noticed the iscsitgtd daemon wouldn't run. It requires libxml2, but it only has the 32bit version. So symlinking the libxml2.so.2 will not work.

I am using a 64bit system.

Following output I get:

# /usr/sbin/amd64/iscsitgtd
ld.so.1: iscsitgtd: fatal: libxml2.so.2: open failed: No such file or directory
ld.so.1: iscsitgtd: fatal: relocation error: file /usr/sbin/amd64/iscsitgtd: symbol xmlCheckVersion: referenced symbol not found
Killed

After symlinking /usr/lib/64/libxml2.so.2 to /usr/lib/libxml2.so.2
# /usr/sbin/amd64/iscsitgtd
ld.so.1: iscsitgtd: fatal: /usr/lib/64/libxml2.so.2: wrong ELF class: ELFCLASS32
ld.so.1: iscsitgtd: fatal: relocation error: file /usr/sbin/amd64/iscsitgtd: symbol xmlCheckVersion: referenced symbol not found

[Tim Spriggs (tim-tajinc)]

I have a 64-bit libxml2 build in the repository but it does not fix the real bug of this report: iscsitgtd daemon won't run

# ldd /usr/sbin/amd64/iscsitgtd | egrep file\ not\ found\|libxml2
 libxml2.so.2 => /usr/lib/64/libxml2.so.2
 libxml2.so.2 (SUNW_1.4) => (version not found)
 libxml2.so.2 (SUNW_1.4) => (version not found)
 libnspr4.so => (file not found)
 libplc4.so => (file not found)
 libnss3.so => (file not found)
 libssl3.so => (file not found)

it looks like libxml2 (and friends) need to come from the onnv base/build or iscsitgtd needs to be rebuilt to use the gnu userland equivs. Unless the community picks this up, this may not be fixed by NCP2.0/hardy release.

[Erast (erast)]

Actually, I think it is a serious problem. But it is not related to libxml2, probably new bug needs to be created...

Take a look on libnspr4 and libnss3 packages in Hardy and you'll see that they came from firefox 1.5 - i.e. just uploaded form elatte => hardy!!!

Instead we need to build upstream source packages (yes they separated them from firefox now):

http://packages.ubuntu.com/source/hardy/nss
http://packages.ubuntu.com/source/hardy/nspr

And if we could provide 64-bit nss nspr libraries - then this bug could be closed as well.

[Tim Spriggs (tim-tajinc)]

Erast wrote:
> Actually, I think it is a serious problem. But it is not related to
> libxml2, probably new bug needs to be created...
>
> Take a look on libnspr4 and libnss3 packages in Hardy and you'll see
> that they came from firefox 1.5 - i.e. just uploaded form elatte =>
> hardy!!!
>
> Instead we need to build upstream source packages (yes they separated
> them from firefox now):
>
> http://packages.ubuntu.com/source/hardy/nss
> http://packages.ubuntu.com/source/hardy/nspr
>
> And if we could provide 64-bit nss nspr libraries - then this bug could
> be closed as well.
>
It's worth noting that hardy-updates has a newer source revision for
both packages:

http://packages.ubuntu.com/source/hardy-updates/nss
http://packages.ubuntu.com/source/hardy-updates/nspr

and both newer source versions are already in the nexenta hardy-unstable
source repository.

[Erast (erast)]

Ok. We should remove old binaries from the nexenta unstable and examine the impact on dependencies I guess.

[Tim Spriggs (tim-tajinc)]

Erast wrote:
> Ok. We should remove old binaries from the nexenta unstable and examine
> the impact on dependencies I guess.
>
well, we still need the new binaries... only the source has been imported.

[Tim Spriggs (tim-tajinc)]

The nspr/nss packages have been built with 32 bit and 64 bit versions.

Installing libnss3-1d and libnspr4-0d allow iscsitgtd to run.