Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: issue with epics in python
From: Matt Newville <newville@cars.uchicago.edu>
To: Cyrille Thomas <Cyrille.Thomas@esss.se>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 27 Sep 2017 11:23:49 -0500
Hi Cyrille, 


On Wed, Sep 27, 2017 at 4:50 AM, Cyrille Thomas <Cyrille.Thomas@esss.se> wrote:

Hi,

 

 

I just installed pyepics on my mac, followed the instruction but got an error message when running a script.

Can you help me to find the bug?

 

Here is what I have done: 

I installed epics base 3.15.4 and make in the folder

I run the command NOLIBCA=1 pip install pyepics

Then run the script and then got the following error:

 

python DTU_acquisition_script.py 

Traceback (most recent call last):

  File "/Users/cyrillethomas/anaconda/lib/python3.6/site-packages/epics/ca.py", line 252, in initialize_libca

    libca = load_dll(find_libca())

  File "/Users/cyrillethomas/anaconda/lib/python3.6/ctypes/__init__.py", line 426, in LoadLibrary

    return self._dlltype(name)

  File "/Users/cyrillethomas/anaconda/lib/python3.6/ctypes/__init__.py", line 348, in __init__

    self._handle = _dlopen(self._name, mode)

OSError: dlopen(/Users/cyrillethomas/epicsbase/base-3.15.4/lib/darwin-x86/libca.dylib, 6): Symbol not found: _EPICS_CA_ADDR_LIST

  Referenced from: /Users/cyrillethomas/epicsbase/base-3.15.4/lib/darwin-x86/libca.dylib

  Expected in: flat namespace

 in /Users/cyrillethomas/epicsbase/base-3.15.4/lib/darwin-x86/libca.dylib

Traceback (most recent call last):

  File "/Users/cyrillethomas/anaconda/lib/python3.6/site-packages/epics/ca.py", line 252, in initialize_libca

    libca = load_dll(find_libca())

  File "/Users/cyrillethomas/anaconda/lib/python3.6/ctypes/__init__.py", line 426, in LoadLibrary

    return self._dlltype(name)

  File "/Users/cyrillethomas/anaconda/lib/python3.6/ctypes/__init__.py", line 348, in __init__

    self._handle = _dlopen(self._name, mode)

OSError: dlopen(/Users/cyrillethomas/epicsbase/base-3.15.4/lib/darwin-x86/libca.dylib, 6): Symbol not found: _EPICS_CA_ADDR_LIST

  Referenced from: /Users/cyrillethomas/epicsbase/base-3.15.4/lib/darwin-x86/libca.dylib

  Expected in: flat namespace

 in /Users/cyrillethomas/epicsbase/base-3.15.4/lib/darwin-x86/libca.dylib

 

 

Sorry for the trouble. I believe that this message comes from trying to explicitly load libCom prior to libca.  I don't fully understand why doing this causes that set of error messages, but the simplest, quickest fix for you right now is to comment out ..../site-packages/epics/ca.py line 251 which reads
          load_dll(find_libCom())

For me, on a Mac OSX with a fresh install using `pip install`, I could both reproduce this problem and avoid it with that fix. I think it will work for you.

Longer answer:  Over the past couple years, we have been seeing more conflicts with pyepics vs. locally generated versions of libca, and libCom in particular.   Most of these problems are seen with Anaconda Python, which uses its own version of readline that may conflict with the system default readline.  Since, by default, libCom is build with readline support on Linux, it is easy to find Linux systems for which the system-generated libCom/libca pair cannot be loaded by Anaconda Python without some effort (like, changing Anaconda's readline).  This is unfortunate because libca does not ever use readline, while an interactive program like 'python' might very well have a use for it.  

Because of this, pyepics now (as of 3.2.7) distributes versions of ca and Com libraries for Win32, Win64, OSX, and Linux64 that should work (built without readline, and relocatable).  You can override these libraries, and you can choose to not install them (as you have done) with NOLIBCA=1 option to `pip install`.  But also, we do test with exactly the distributed versions, so they should work and choosing to use your own versions of libca/libCom is much harder for us to support.

But also, and in fairness: we have seen several problems in version 3.2.7 with the way these libraries are installed and then searched for, especially given the variations in how Python packages can be installed.  So, we (mostly Daron Chabot) have made a lot of changes since version 3.2.7 that should fix these problems, including the one you see on OSX.   These are available in the github master branch, and we're expecting to release 3.3.0 which will better fix these problems soon (within a week or so). 
 
Hope that helps,

--Matt


References:
issue with epics in python Cyrille Thomas

Navigate by Date:
Prev: Re: registerRecordDeviceDriver.pl takes a long time to finish Michael Davidsaver
Next: Re: registerRecordDeviceDriver.pl takes a long time to finish Johnson, Andrew N.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: issue with epics in python Cyrille Thomas
Next: registerRecordDeviceDriver.pl takes a long time to finish Hinko Kocevar
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 27 Sep 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·