Maybe it worked for Sam but not for me.
Either way around (i386 or x86_64 first), when installing the second rpm
there are, unsurprisingly, conflicts. So it would have to be forced.
Another reason why this is wrong is that surely the WN should be
correctly installed by just installing the WN meta-rpm, not all this
fiddling? I mean, I don't mind doing whatever is needed to get it
working now, but please could the request to make this work properly be
fed up the chain with some urgency?
Unless I am missing something...
Surprised no one else complained about this.
Cheers,
Simon
Wahid Bhimji wrote:
> Hi
>
> Simon George wrote:
>> Hi,
>>
>> thanks for your feedback Sam and Wahid. So is the conclusion that we
>> only need the 32-bit libs and can uninstall the 64-bit version?
> Yes - you only need the 32 bit libs. But if you install the 64 bit rpm
> after the 32 bit ones then I think you will get both.
> /opt/lcg/lib/libdpm.so.1.7.3,
> and /opt/lcg/lib64/libdpm.so.1.7.3
> Sam indicated he got this just following the standard installation - no
> forcing required - maybe something has changed in the repo.
> We (ECDF) use the tarball WN so I don't know if forcing the rpm install
> is necessary (but we also have the 32 bit libs)
>
> Wahid
>
>> If we need both, then could dpm developers be asked to provide rpms
>> that can both be installed without --force? i.e. take out the common
>> files into a separate rpm that both 32-bit and 64-bit libs depend on,
>> then you can install either or both cleanly.
>>
>> Cheers,
>> Simon
>>
>> Wahid Bhimji wrote:
>>> Hi,
>>> actually I was trying to use the 64bit client recently (as I only had
>>> a 64bit version of the test rfio client).
>>> I couldn't - as the recent athena kits seem to only have 32bit
>>> versions. So yes I think you will need the 32bit libs.
>>>
>>> Wahid
>>>
>>> Sam Skipsey wrote:
>>>> Hello, all,
>>>>
>>>> Indeed, we managed to install both the i386 and the x86_64 versions
>>>> of DPM-client - the 64bit one last, so that we get the 64bit
>>>> binaries, but the 32bit libraries still exist in lib.
>>>>
>>>> Of course, the actual solution is for everyone (and every
>>>> experiment!) to (eventually) move entirely to SL5/64bit, in which
>>>> case the problem vanishes. Multiple bitnesses of libraries are
>>>> always a little annoying.
>>>>
>>>> Sam
>>>>
>>>> On 28 May 2010 08:55, <[log in to unmask]
>>>> <mailto:[log in to unmask]>> wrote:
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Duncan Rand [mailto:[log in to unmask]
>>>> <mailto:[log in to unmask]>]
>>>> Sent: 27 May 2010 16:51
>>>> To: ATLAS UK Cloud Support
>>>> Cc: Simon George
>>>> Subject: rfio
>>>>
>>>> Hi
>>>>
>>>> RHUL are failing the rfio gangarobot test, e.g.
>>>>
>>>> http://gangarobot.cern.ch/20100527_01/
>>>>
>>>> Message: (file
>>>>
>>>> "/vosw/atlas/prod/releases/rel_15-21/DetCommon/15.6.9/InstallArea/i686-s
>>>>
>>>> lc5-gcc43-opt/lib/libRFIO.so",
>>>> line 1) dlopen error: libshift.so.2.1: cannot open shared object
>>>> file:
>>>> No such file or directory
>>>>
>>>> and in the job scratch directory listing further up the file we see
>>>>
>>>> lrwxrwxrwx 1 atlas002 atlas 22 May 27 01:11 libshift.so.2.1 ->
>>>> /opt/lcg/lib/libdpm.so
>>>>
>>>> now
>>>>
>>>> [root@node001 ~]# rpm -ql DPM-client-1.7.3-1sec.sl5.x86_64|grep
>>>> libdpm
>>>> /opt/lcg/lib64/libdpm.a /opt/lcg/lib64/libdpm.so
>>>> /opt/lcg/lib64/libdpm.so.1.7.3
>>>>
>>>> so it looks like we might need the i386 version of DPM-client,
>>>> what do
>>>> you think?
>>>>
>>>> A quick glance at the repos in /etc/yum.repos.d/glite-WN.repo
>>>> indicate
>>>> it is already there so I guess something like
>>>>
>>>> yum install DPM-client.i386
>>>>
>>>> might be enough. But we get conflicts like:
>>>>
>>>> file /opt/lcg/bin/dpm-rmfs from install of
>>>> DPM-client-1.7.3-1sec.sl5.i386 conflicts with file from package
>>>> DPM-client-1.7.3-1sec.sl5.x86_64
>>>>
>>>> I understand from Sam/Dug that Glasgow have both 32 and 64 bit
>>>> versions
>>>> of DPM-client installed. Is this the right way to solve this
>>>> problem?
>>>>
>>>> thanks
>>>> Duncan
>>>>
>>>>
>>>
>>>
>>
>
>
|