Re: PyTango Undefined symbol DeviceData

[Giacomo S.]

Hello Tiago, after some time I put down to try to build and run PyTango
on my computer.
Together with Claudio and Roberto, our system administration, I ran
again into undefined symbols when importing PyTango

Python 3.4.4 (default, Jun 13 2016, 14:49:50)
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyTango import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.4/site-packages/PyTango/__init__.py", line
120, in <module>
from . import _PyTango
ImportError:
/usr/lib64/python3.4/site-packages/PyTango/_PyTango.cpython-34m.so:
undefined symbol: _ZN5Tango11DeviceProxy14get_corba_nameB5cxx11Eb


The output from Roberto is this (Python 2.7):

Python 2.7.11 (default, Mar 30 2016, 15:58:11)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyTango
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/usr/local/python-2.7.11/lib/python2.7/site-packages/PyTango/__init__.py",
line 120, in <module>
from . import _PyTango
ImportError:
/usr/local/python-2.7.11/lib/python2.7/site-packages/PyTango/_PyTango.so: undefined
symbol: _ZN5Tango10DeviceDataaSEOS0_

I also tried to build PyTango with python 2.7 and I got the very same
undefined symbol "_ZN5Tango11DeviceProxy14get_corba_nameB5cxx11Eb"

I took special care to be sure to build both tango8.1.2.c and PyTango
with -std=c++98 (using CXXFLAGS=...)

I attach the output from

nm /usr/lib64/python3.4/site-packages/PyTango/_PyTango.cpython-34m.so >
PyTango.cpython-34m.nm

nm /usr/local/tango-8.1.2.c/lib/libtango.so.8 >Tango.nm

as you requested, hoping to find a solution to our problem and start
trying taurus as soon as possible.

Finally, is Python3 fully supported?

I get this error during the install process:


raise result.error_string, None, result.tb
^
SyntaxError: invalid syntax

Thanks, Giacomo.



On 03/11/2015 08:36 AM, coutinho wrote:
> Hi Giacomo,
>
>
> Problem 1
> ---------
>
> Ok, the first problem due to the fact that some linux distributions up
> until some point in time distributed libboost-python.so without caring
> about the python version.
> Afterward, Debian based systems added libboost-python-pyXY.so.
> Thanks to Frederic PICCA patch in PyTango setup.py, it works for
> debian based systems now.
> Unfortunately your system uses libboost-python-pyX.Y.so (notice the
> extra "." between "X" and "Y").
> If you can give me the output of:
>
> $ python -c "import platform; print(platform.linux_distribution())"
>
> I can add the exception to PyTango setup.py.
>
> BTW, in my linux Mint (debian based) by default there is the
> symbolic link you created manually. I think it is a mistake because if
> you use python3 you will be in trouble!
>
> Problem 2
> ---------
>
> I know in GCC 4.8 they are more strict in the argument order but I
> tested in a Linux Mint 17.1 and it works. Furthermore, the ldd shows
> that _PyTango.so is properly linked.
>
> Could you do:
>
> $ nm /usr/lib64/python2.7/site-packages/PyTango/_PyTango.so >PyTango.nm
> $ nm /usr/local/tango-8.1.2.c/lib/libtango.so.8 >Tango.nm
>
> and send me the generated PyTango.nm and Tango.nm files?
>
> It could help me to find your problem.
>
> Thanks in advance
>
> Cheers
> Tiago
>
> On 03/10/2015 04:53 PM, Giacomo S. wrote:
>> Hi Tiago,
>>
>> some additional information I forgot to mention in my last email:
>>
>> python version used:
>>
>> Konsole output
>> Python 2.7.9 (default, Feb 9 2015, 09:28:21)
>> [GCC 4.8.4] on linux2
>>
>> GCC info:
>>
>> Konsole output
>> giacomo@woody~/devel/fermi/panels/power_supply/psgroupmanager $gcc -v
>> Using built-in specs.
>> COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4/gcc
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.4/lto-wrapper
>>
>> Target: x86_64-pc-linux-gnu
>> Configured with:
>> /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/configure
>> --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --
>> bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.4
>> --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/include
>> --datadir=/usr/share/gcc-data/x86_64-pc-linu
>> x-gnu/4.8.4 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.4/man
>> --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.4/info
>> --with-gxx-include
>> -dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/include/g++-v4
>> --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.4/python
>> --enable-languages=c,c++
>> ,fortran --enable-obsolete --enable-secureplt --disable-werror
>> --with-system-zlib --enable-nls --without-included-gettext
>> --enable-checking=release --
>> with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.4
>> p1.0, pie-0.6.1' --enable-libstdcxx-time --enable-shared
>> --enable-threads=posix -
>> -enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
>> --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point
>> --enable-targets=all
>> --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp
>> --enable-lto --without-cloog --enable-libsanitizer
>> Thread model: posix
>> gcc version 4.8.4 (Gentoo 4.8.4 p1.0, pie-0.6.1)
>>
>> I don't know if my issue can be related to c++98/c++11 standard settings
>> used at compile time to build tango and PyTango.
>> AFAICS, I didn't explicitly set any flag to enable/disable this feature.
>> I can't think of anything else for this strange issue.
>>
>> Doing a google search, I came across this document:
>>
>> http://stackoverflow.com/questions/11643666/python-importerror-undefined-symbol-for-custom-c-module
>>
>>
>> but that's all.
>>
>> Thanks for any advice,
>>
>> Giacomo.
>>
>>
>>
>>
>> On 03/10/15 14:37, Giacomo S. wrote:
>>> Hi Tiago
>>>
>>>
>>> On 03/10/15 14:15, coutinho wrote:
>>>> Hi Giacomo,
>>>>
>>>> On 03/10/2015 10:40 AM, Giacomo S. wrote:
>>>>> Good morning to everybody.
>>>>>
>>>>> I successfully installed PyTango (8.1.6) and Taurus (3.40).
>>>>>
>>>>> One observation and one issue.
>>>>>
>>>>> The observation: having 2.x and 3.x python versions installed,
>>>>> there was
>>>>> a linking problem with
>>>>>
>>>>> Konsole output
>>>>> libboost_python
>>>>>
>>>>> because in my system there is
>>>>>
>>>>> Konsole output Konsole output
>>>>> /usr/lib64/libboost_python-2.7.so
>>>>>
>>>>> and
>>>>>
>>>>> Konsole output
>>>>> /usr/lib64/libboost_python-3.3.so
>>>>>
>>>>> but no libboost_python.so
>>>>>
>>>>> So I had to work it around with a hack, making a symlink
>>>>>
>>>>> Konsole output
>>>>> /usr/lib64/libboost_python.so-> /usr/lib64/libboost_python-2.7.so
>>>>>
>>>>> in order to successfully build the python stuff.
>>>>> Is there a way to fix this?
>>>> if you have python 2.x and 3.y installed you should need:
>>>> libboost_python-2.7.so and
>>>> libboost_python-3.3.so
>>> Indeed, it' like that:
>>>
>>> Konsole output Konsole output
>>> woodyDownloads #ls /usr/lib64/libboost_python* -l
>>> lrwxrwxrwx 1 root root 22 Dec 29 09:41
>>> /usr/lib64/libboost_python-2.7-mt.so-> libboost_python-2.7.so
>>> lrwxrwxrwx 1 root root 29 Dec 29 09:41
>>> /usr/lib64/libboost_python-2.7.so-> libboost_python-2.7.so.1.56.0
>>> -rwxr-xr-x 1 root root 327320 Dec 29 09:41
>>> /usr/lib64/libboost_python-2.7.so.1.56.0
>>> lrwxrwxrwx 1 root root 22 Dec 29 09:41
>>> /usr/lib64/libboost_python-3.3-mt.so-> libboost_python-3.3.so
>>> lrwxrwxrwx 1 root root 29 Dec 29 09:41
>>> /usr/lib64/libboost_python-3.3.so-> libboost_python-3.3.so.1.56.0
>>> -rwxr-xr-x 1 root root 323384 Dec 29 09:41
>>> /usr/lib64/libboost_python-3.3.so.1.56.0
>>> lrwxrwxrwx 1 root root 33 Mar 9 14:53
>>> /usr/lib64/libboost_python.so-> /usr/lib64/libboost_python-2.7.so
>>>
>>> I had to manually add the last one (/usr/lib64/libboost_python.so) in
>>> order to be able to compile the Python stuff.
>>>
>>>
>>>> the symlink you did only works if you are using python 2.7
>>> Is python 3 supported by PyTango and Taurus?
>>>
>>>> Which linux distribution are you using?
>>>> In debian based there are two packages of libboost-python: one for 2.x
>>>> and another for 3.y
>>>>
>>>>> The problem:
>>>>>
>>>>> Konsole output
>>>>> giacomo@woody~/devel/PyTango-8.1.6 $python2
>>>>> Python 2.7.9 (default, Feb 9 2015, 09:28:21)
>>>>> [GCC 4.8.4] on linux2
>>>>> Type "help", "copyright", "credits" or "license" for more
>>>>> information.
>>>>> >>> import PyTango
>>>>> Traceback (most recent call last):
>>>>> File "<stdin>", line 1, in <module>
>>>>> File "/usr/lib64/python2.7/site-packages/PyTango/__init__.py",
>>>>> line
>>>>> 120, in <module>
>>>>> from . import _PyTango
>>>>> ImportError: /usr/lib64/python2.7/site-packages/PyTango/_PyTango.so:
>>>>> undefined symbol: _ZN5Tango10DeviceDataaSEOS0_
>>>>>
>>>>>
>>>>> event though
>>>>>
>>>>> Konsole output
>>>>> giacomo@woody~/devel/PyTango-8.1.6 $ldd
>>>>> /usr/lib64/python2.7/site-packages/PyTango/_PyTango.so
>>>>> linux-vdso.so.1 (0x00007fff771d5000)
>>>>> libtango.so.8 => /usr/local/tango-8.1.2.c/lib/libtango.so.8
>>>>> (0x00007f00bcf49000)
>>>>> libomniORB4.so.1 =>
>>>>> /usr/local/omniorb-4.1.6/lib/libomniORB4.so.1 (0x00007f00bcb93000)
>>>>> libboost_python-2.7.so.1.56.0 =>
>>>>> /usr/lib64/libboost_python-2.7.so.1.56.0 (0x00007f00bc902000)
>>>>> libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
>>>>> (0x00007f00bc53f000)
>>>>> libstdc++.so.6 =>
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libstdc++.so.6
>>>>> (0x00007f00bc22e000)
>>>>> libm.so.6 => /lib64/libm.so.6 (0x00007f00bbf35000)
>>>>> libgcc_s.so.1 =>
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libgcc_s.so.1
>>>>> (0x00007f00bbd1e000)
>>>>> libpthread.so.0 => /lib64/libpthread.so.0
>>>>> (0x00007f00bbb02000)
>>>>> libc.so.6 => /lib64/libc.so.6 (0x00007f00bb76a000)
>>>>> liblog4tango.so.5 =>
>>>>> /usr/local/tango-8.1.2.c/lib/liblog4tango.so.5 (0x00007f00bb551000)
>>>>> libzmq.so.3 => /usr/local/lib64/libzmq.so.3
>>>>> (0x00007f00bb30a000)
>>>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007f00bb106000)
>>>>> libomniDynamic4.so.1 =>
>>>>> /usr/local/omniorb-4.1.6/lib/libomniDynamic4.so.1
>>>>> (0x00007f00bac0b000)
>>>>> libCOS4.so.1 => /usr/local/omniorb-4.1.6/lib/libCOS4.so.1
>>>>> (0x00007f00ba7cb000)
>>>>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f00ba5b3000)
>>>>> libomnithread.so.3 =>
>>>>> /usr/local/omniorb-4.1.6/lib/libomnithread.so.3 (0x00007f00ba3ad000)
>>>>> libutil.so.1 => /lib64/libutil.so.1 (0x00007f00ba1a9000)
>>>>> librt.so.1 => /lib64/librt.so.1 (0x00007f00b9fa1000)
>>>>> /lib64/ld-linux-x86-64.so.2 (0x00007f00bebeb000)
>>>>>
>>>>>
>>>>>
>>>>> And include paths and link paths were correct at compile time.
>>>>>
>>>>> Moreover:
>>>>>
>>>>> Konsole output
>>>>>>>> import os
>>>>> >>> os.environ['LD_LIBRARY_PATH']
>>>>> '/usr/local/mathgl/lib:/usr/local/qwt-5.2.1-qt5/lib:/usr/local/qt5/lib:/usr/local/qwt-5.2.1/lib:/usr/local/tango-8.1.2.c/lib:/usr/loc
>>>>>
>>>>>
>>>>> al/omniorb-4.1.6/lib:/runtime/lib:/runtime/lib/plugins/designer'
>>>>>
>>>>>
>>>>> Thanks for any hint.
>>>>>
>>>>> Giacomo.
>>>> How did you compile PyTango?
>>>> Did you have the same problem with older version of PyTango?
>>> I tried with PyTango Konsole outpu 8.1.6 and PyTango-8.1.5, the same.
>>>
>>> I ran:
>>>
>>> python setup.py build
>>> python setup.py install (as root)
>>>
>>> Thanks to you!
>>>
>>> G
>>>
>>>> Thanks in advance
>>>>
>>>>
>>>> Tiago
>>>>
>>

[Vincent Michel]

Hi Giacomo,

I had a similar error a few months ago. The problem was that PyTango
uses `/usr/local/lib/libtango.so`, and it was linked to
`libtango.so.9.1.0` instead of `libtango.so.8.1.2`. Do you have Tango 9
installed on your machine by any chance?

The python3 error your report has been fixed in this commit:
https://github.com/tango-cs/PyTango/commit/873d968fc0e654b387eca24beef35934c9a9212f

I did build a python3 version of pytango a few weeks ago, and it worked
fine (I had to fix the itango script though).

Could you try again with the latest version from develop?

Also, feel free to report your issues directly on github:
https://github.com/tango-cs/PyTango/issues

Cheers,
/Vincent

[Giacomo S.]

Hello, thanks Vincent.
I seem to have solved the issue making sure the compiler and compiler
options were exactly the same as the ones used when
building tango 8.
In my specific case, tango8 was previously built with a gcc 4.x compiler.
Then PyTango was built with gcc 5.3.
Even if the build options were the same, the 5.3 appeared to insert a
"CXX11" string in the function symbols, thus making resolution
impossible at runtime.

I had to switch my entire build environment to the old gcc 4.8, rebuild
tango and then PyTango.
Switching the compiler only with the CXX env variable wasn't enough,
because then libtool wasn't able to generate the libtango.so shared library.

Tango 8 does not build with gcc 5.x compiler though.

This seems to solve my problem.

Thanks for your suggestion anyway.

Giacomo.