Hi Lars,

seems to work now:

# ldd /omd/versions/1.31.20160613/bin/python
        linux-vdso.so.1 =>  (0x00007ffd7bf95000)
        libpython2.7.so.1.0 =>
/omd/versions/1.31.20160613/lib/libpython2.7.so.1.0 (0x00007f151918e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1518f33000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f1518d2f000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f1518b2c000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f15188b2000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f1518536000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1519576000)

So I can remove /omd/versions/default/lib from my ldconfig path :)

Thank you!

Werner

Lars Michelsen [13.06.2016 09:15]:
> Hi Werner,
> 
> Please wait for the 20160613 build, it should fix this issue. Seems the 
> build system was caching some things so my change did not apply.
> 
> Best regards
> Lars
> 
> On 13.06.2016 09:01, Werner Flamme wrote:
>> Hi Lars,
>>
>> I erased version 20160610, because it wouldn't work as desired.
>>
>> But with 20160612 it looks very similar:
>>
>> # omd sites
>> /omd/versions/1.31.20160612/bin/python: error while loading shared
>> libraries: libpython2.7.so.1.0: cannot open shared object file: No such
>> file or directory
>>
>> # ldd /omd/versions/1.31.20160612/bin/python
>>          linux-vdso.so.1 =>  (0x00007ffdc4355000)
>>          libpython2.7.so.1.0 => not found
>>          libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f67f44f0000)
>>          libdl.so.2 => /lib64/libdl.so.2 (0x00007f67f42ec000)
>>          libutil.so.1 => /lib64/libutil.so.1 (0x00007f67f40e9000)
>>          libm.so.6 => /lib64/libm.so.6 (0x00007f67f3e6f000)
>>          libc.so.6 => /lib64/libc.so.6 (0x00007f67f3af3000)
>>          /lib64/ld-linux-x86-64.so.2 (0x00007f67f474c000)
>>
>> # find /omd/versions/1.31.20160612/ -name 'libpython*'
>> /omd/versions/1.31.20160612/lib/libpython2.7.so
>> /omd/versions/1.31.20160612/lib/libpython2.7.so.1.0
>> /omd/versions/1.31.20160612/lib/python2.7/config/libpython2.7.a
>>
>> After "su - sap" it works:
>>
>> # su - sap
>> OMD[sap]:~$ omd sites
>> SITE             VERSION          COMMENTS
>> archivemon       1.30
>> mysqlmon         1.30
>> oramon           1.30
>> sap              1.31.20160604
>> test1            1.31.20160604    disabled
>> test2            1.31.20160604    disabled
>>
>> So I created file /etc/ld.so.conf.d/omd.conf containing the line
>> /omd/versions/default/lib
>> invoked "ldconfig" and voila:
>>
>> # ldconfig -p | grep libpython
>>          libpython2.7.so.1.0 (libc6,x86-64) =>
>> /omd/versions/default/lib/libpython2.7.so.1.0
>>          libpython2.7.so (libc6,x86-64) =>
>> /omd/versions/default/lib/libpython2.7.so
>>          libpython2.6.so.1.0 (libc6,x86-64) => /usr/lib64/libpython2.6.so.1.0
>>          libpython2.6.so.1.0 (libc6) => /usr/lib/libpython2.6.so.1.0
>>          libpython2.6.so (libc6,x86-64) => /usr/lib64/libpython2.6.so
>>
>> # omd sites
>> SITE             VERSION          COMMENTS
>> archivemon       1.30
>> mysqlmon         1.30
>> oramon           1.30
>> sap              1.31.20160604
>> test1            1.31.20160604    disabled
>> test2            1.31.20160604    disabled
>>
>> Works now. Maybe the next versions can bring a file for
>> /etc/ld.so.conf.d/ by themselves ;)
>>
>> Regards,
>> Werner
>>
>> Lars Michelsen [10.06.2016 19:35]:
>>> Hi Werner,
>>>
>>> please run this command and send me the output:
>>>
>>> ldd /omd/versions/1.31.20160610/bin/python
>>>
>>> For me it shows something like this:
>>>
>>>   > ldd /omd/versions/2016.06.10.cee/bin/python
>>>       linux-vdso.so.1 =>  (0x00007ffd8fbd6000)
>>>       libpython2.7.so.1.0 =>
>>> /omd/versions/2016.06.10.cee/lib/libpython2.7.so.1.0 (0x00007f75eeef0000)
>>>       libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>>> (0x00007f75eecaf000)
>>>       libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f75ee8e5000)
>>>       libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f75ee6e1000)
>>>       libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 
>>> (0x00007f75ee4de000)
>>>       libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f75ee1d4000)
>>>       /lib64/ld-linux-x86-64.so.2 (0x0000560920707000)
>>>
>>> The important part is the line where you see libpython2.7.so.1.0.
>>> This needs to point to the OMD version path.
>>>
>>> Andreas already mentioned it. I am in progress integrating Python 2.7
>>> into OMD for all supported platforms.
>>> This Python is fully independent from the system global Python installation.
>>>
>>> Best regards
>>> Lars
>>>
>>> On 10.06.2016 12:31, Werner Flamme wrote:
>>>> Hello OMDlers,
>>>>
>>>> I just did a "zypper up", which pulled omd-daily and, as a dependency,
>>>> omd-daily-1.31.20160610 (from
>>>> http://labs.consol.de/repo/testing/sles11sp3/x86_64, which is defined as
>>>> a repository).
>>>>
>>>> My next step was "omd sites", but then I had to stop:
>>>>
>>>> /omd/versions/1.31.20160610/bin/python: error while loading shared
>>>> libraries: libpython2.7.so.1.0: cannot open shared object file: No such
>>>> file or directory
>>>>
>>>> SLES 11 SP4 only has /usr/lib64/libpython2.6.so.1.0. Python 2.7 is only
>>>> available in a home: repository in the OBS, so I can't install it on a
>>>> company's host.
>>>>
>>>> I'd recommend to mention libpython2.7.so.1.0 as a "requires:" in the
>>>> rpm, since this would prevent zypper from downloading and installing. Of
>>>> course, it would be better to still use libpython2.6 ;)
>>>>
>>>> Regards,
>>>> Werner


-- 


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
omd-users mailing list
[email protected]
http://lists.mathias-kettner.de/mailman/listinfo/omd-users

Reply via email to