Shared library issue on OSX

[ghost]

The shared library pvaccess.dylib does not work on OSX Yosemite(not sure about other OSX versions but we tested on 4 different machines). The issue goes away if .dylib -> .so linked manually.

[gregoryraymondwhite]

Hi Arman,

Sorry to hear that.

By "does not work" do you mean "did not build" or do you mean "does not execute successfully"?

Could you give some details:
Did you build v 4.4 from distribution?
Also, did you follow the instructions in the Getting Started for MAC OS X?
http://epics-pvdata.sourceforge.net/gettingStarted.html#appendix_b:_help_with_mac_os_x_build

By the way, in my 4.4 build (which was done while on Mountain Lion, but whose build products continue to work on Yosemite), the outcome is:

EPICS-CPP-4.4.0/pvAccessCPP] greg% ls lib/darwin-x86/
total 47728
0 drwxr-xr-x 5 root 1200245 170 May 22 11:21 ./
0 drwxr-xr-x 3 root 1200245 102 May 22 10:44 ../
4088 -r--r--r-- 1 root 1200245 2089108 Dec 12 2014 libpvAccess.3.14.12.dylib
43632 -r--r--r-- 1 root 1200245 22339096 Dec 12 2014 libpvAccess.a
8 lrwxr-xr-x 1 root 1200245 25 Dec 12 2014 libpvAccess.dylib@ -> libpvAccess.3.14.12.dylib

[ghost]

Hi Greg,

Thank you for the reply.

We did build it from the distribution. and we did follow the instructions. Others in my group with Macs have identical issues and we were able to regenerate the problem on different work stations with OSX Yosemite.
Let me provide more details:
It builds fine without any errors. It generates the correct dylib extension. However, the interpreter cannot find the pvaccess at import time. It is not a python path problem either. We have verified the path very carefully.
In Yosemite, we had to link dylib to so extension for interpreter to successfully import pvaccess. This is the only thing we needed to do in order to import and use pvaPy.

I have used pvaPy on Mountain Lion w/o any issues as well. I have tried the build using the python from homebrew(not sure what others used but I can verify once I talk to them).

[gregoryraymondwhite]

[Autoconf experts, some help would be appreciated with how to get autoconf to be more verbose
about the test that failed - thanks in advance].

Hi Arman,

Well, I tried to reproduce your issue. I have a Mac running Yosemite on which I had
not built pvaPy, so I thought I’d try it.

But I didn’t get even as far as you. After installing prerequisites autoconf and boost, I get
the following from pvaPy “make configure”:

pvaPy greg$ make configure
...
checking for EPICS base >= 3.14.2... yes
checking for usable EPICS base libraries for Darwin OS and host architecture darwin-x86... no
configure: error: could not compile and link EPICS test code: check your EPICS base installation
make: *** [configure] Error 1

My base installation has the libs, as .dylib

$ ls $EPICS_BASE/lib/$EPICS_HOST_ARCH/
total 31896
drwxr-xr-x 51 root wheel 1734 May 22 11:21 ./
drwxr-xr-x 4 root wheel 136 May 22 10:44 ../
-r-xr-xr-x 1 root wheel 68312 Apr 11 2014 Cap5.bundle*
-rw-r--r-- 1 root wheel 474572 Apr 11 2014 libCom.3.14.12.dylib
-r--r--r-- 1 root wheel 1474496 Apr 11 2014 libCom.a
lr--r--r-- 1 root wheel 20 Apr 11 2014 libCom.dylib@ -> libCom.3.14.12.dylib
-rw-r--r-- 1 root wheel 43980 Apr 11 2014 libasHost.3.14.12.dylib
-r--r--r-- 1 root wheel 89992 Apr 11 2014 libasHost.a
lr--r--r-- 1 root wheel 23 Apr 11 2014 libasHost.dylib@ -> libasHost.3.14.12.dylib
-rw-r--r-- 1 root wheel 62912 Apr 11 2014 libasIoc.3.14.12.dylib
-r--r--r-- 1 root wheel 143136 Apr 11 2014 libasIoc.a
…

I can see the code in pvaPy/tools/autoconf/configure which is failing, but I don’t know how to
run make configure in a way to make it spit out more details of the line that failed.

If someone can tell me how to run make configure with verbose output, I’ll try to continue.

Cheers
Greg

On Aug 10, 2015, at 10:44 AM, Arman Arkilic notifications@github.com wrote:

Hi Greg,

Thank you for the reply.

We did build it from the distribution. and we did follow the instructions. Others in my group with Macs have identical issues and we were able to regenerate the problem on different work stations with OSX Yosemite.
Let me provide more details:
It builds fine without any errors. It generates the correct dylib extension. However, the interpreter cannot find the pvaccess at import time. It is not a python path problem either. We have verified the path very carefully.
In Yosemite, we had to link dylib to so extension for interpreter to successfully import pvaccess. This is the only thing we needed to do in order to import and use pvaPy.

I have used pvaPy on Mountain Lion w/o any issues as well. I have tried the build using the python from homebrew(not sure what others used but I can verify once I talk to them).

—
Reply to this email directly or view it on GitHub.

[anjohnson]

Hi Arman,

Does applying this patch solve the problem?

diff --git a/src/pvaccess/Makefile b/src/pvaccess/Makefile
index c873f2d..ef8f5fb 100644
--- a/src/pvaccess/Makefile
+++ b/src/pvaccess/Makefile
@@ -10,6 +10,9 @@ include $(TOP)/configure/CONFIG

 LOADABLE_LIBRARY_HOST += pvaccess
 LOADABLE_SHRLIB_PREFIX = 
+ifeq ($(OS_CLASS),Darwin)
+LOADABLE_SHRLIB_SUFFIX = .so
+endif

 #PROD_HOST_linux-x86_64 += testClient
 PROD_HOST += $(PROD_HOST_$(T_A))

[sveseli]

Hi Andrew and Arman,

If Arman was able to make symlink manually and got it working this patch
will work on Yosemite, but we also have to make sure that it works on
earlier versions of OSX.

I also wonder why "LOADABLE_SHRLIB_PREFIX =" does not seem to work and
we end up with .dylib file...?

Sinisa

On 8/11/2015 3:47 PM, Andrew Johnson wrote:

Hi Arman,

Does applying this patch solve the problem?

diff --git a/src/pvaccess/Makefile b/src/pvaccess/Makefile
index c873f2d..ef8f5fb 100644
--- a/src/pvaccess/Makefile
+++ b/src/pvaccess/Makefile
@@ -10,6 +10,9 @@ include $(TOP)/configure/CONFIG

LOADABLE_LIBRARY_HOST += pvaccess
LOADABLE_SHRLIB_PREFIX =
+ifeq ($(OS_CLASS),Darwin)
+LOADABLE_SHRLIB_SUFFIX = .so
+endif

#PROD_HOST_linux-x86_64 += testClient
PROD_HOST += $(PROD_HOST_$(T_A))

—
Reply to this email directly or view it on GitHub
#6 (comment).

[sveseli]

You should be able to find what you are looking for in config.log file
in your build directory.

On 8/10/2015 5:24 PM, Greg White wrote:

[Autoconf experts, some help would be appreciated with how to get
autoconf to be more verbose
about the test that failed - thanks in advance].

[ghost]

Hello Andrew,

Yes, the patch solves the problem. Will you be submitting a PR?

Arman

[ghost]

FYI, the master does not build correctly. I tested it with my old pvaPy that comes with the 4.4.0 distro and checked out the latest master from git.The master from git

c++ -c              -DUNIX  -Ddarwin     -O3 -g   -Wall      -arch x86_64    -fno-common -fPIC -MMD -g -I/include -DPVA_API_VERSION=440 -DPVA_RPC_API_VERSION=440 -I/usr/local/include -I/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I. -I../O.Common -I. -I.. -I../../../include/os/Darwin -I../../../include -I/Users/arkilic/projects/pipelining/epics/base-3.14.12.4/include/os/Darwin -I/Users/arkilic/projects/pipelining/epics/base-3.14.12.4/include    -I/Users/arkilic/Downloads/EPICS-CPP-4.4.0/pvDataCPP/include  -I/Users/arkilic/Downloads/EPICS-CPP-4.4.0/pvAccessCPP/include      -I/Users/arkilic/Downloads/EPICS-CPP-4.4.0/pvDataCPP/include  -I/Users/arkilic/Downloads/EPICS-CPP-4.4.0/pvAccessCPP/include           ../PyUtility.cpp
../PyPvDataUtility.cpp:1069:59: error: no member named 'copy' in 'epics::pvData::PVField'
        unionPvStructurePtr->getSubField(unionFieldName)->copy(*pvField);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
../PyPvDataUtility.cpp:1105:54: error: no member named 'copy' in 'epics::pvData::PVField'
        unionPvStructurePtr->getSubField(fieldName)->copy(*pvField);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
../PyPvDataUtility.cpp:1243:23: error: no member named 'copy' in 'epics::pvData::PVUnion'
                pvTo->copy(*pvFrom);
                ~~~~  ^
3 errors generated.
make[3]: *** [PyPvDataUtility.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [install.darwin-x86] Error 2
make[1]: *** [pvaccess.install] Error 2
make: *** [src.install] Error 2

[ralphlange]

-I/include looks suspicious. Is this a Darwin thing, or is a required environment variable not set?
(Assuming a -I$(BLABLA)/include definition in the compiler flags or something similar.)

[ghost]

Hi Ralph,

I doubt that it is the issue since stable version from distro has the same -I/include flag. Seems like there are some changes to the other v4 modules and I tried to build it against the old ones from the distro 📦 . So this is not an issue with pvaPy. I need to rebuild the other modules of v4 from github with the latest changes Dave has merged 🎯

[dhickin]

Matej added a new copy API after the 4.4 release.

This was the breaking API change I referred to at MSU which meant we couldn't do a 4.4.1 release.

[anjohnson]

Sinisa wrote:

we also have to make sure that it works on earlier versions of OSX.

I don't think that will be a problem, all the Mac python versions I have access to use .so for their loadable libraries. The issue on Yosemite may be that they don't allow .dylib any more (or they forgot to enable it).

I also wonder why "LOADABLE_SHRLIB_PREFIX =" does not seem to work and
we end up with .dylib file...?

It does work, the PREFIX setting in your Makefile removes the 'lib' that would otherwise be prepended to the loadable library name. My patch sets the SUFFIX variable to use the .so that python wants.

I don't intend to submit a pull request, I'll leave you to apply the patch yourself.

[sveseli]

Andrew,

Right, I guess I should learn the difference between suffix and prefix, and
also not respond to emails at 4am... :-)

In any case, this patch has been applied.

Arman,

Could you please verify things now work, and whether this can be closed?

Thanks,

Sinisa

On Wed, Aug 12, 2015 at 10:44 AM, Andrew Johnson notifications@github.com
wrote:

Sinisa wrote:

we also have to make sure that it works on earlier versions of OSX.

I don't think that will be a problem, all the Mac python versions I have
access to use .so for their loadable libraries. The issue on Yosemite may
be that they don't allow .dylib any more (or they forgot to enable it).

I also wonder why "LOADABLE_SHRLIB_PREFIX =" does not seem to work and
we end up with .dylib file...?

It does work, the PREFIX setting in your Makefile removes the 'lib' that
would otherwise be prepended to the loadable library name. My patch sets
the SUFFIX variable to use the .so that python wants.

I don't intend to submit a pull request, I'll leave you to apply the patch
yourself.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[ghost]

Hi Sinisa,

The patch does work. Should we add this to README (btw, the documentation rocks) or would you like me to submit a PR? We have at least 5 users here on Yosemite that are either using/will start using pvaPy very shortly. I am doing my best to urge people to use it here since most are just building their beamlines. It is my goal to make all of them adopt v4 and python seems like the easiest path for their very first applications.

[gregoryraymondwhite]

Arman, Sinisa,

If you update the repo with the patch and Ernest’s discovered updates for the README, I’ll
try a clean build for Yosemite following the instructions as given.

We’re about to have a number of physicists and operators use it, many on Yosemite, so
I want to make sure it works out of the box.

Cheers
Greg

On Aug 12, 2015, at 9:57 AM, sveseli notifications@github.com wrote:

Hi Sinisa,

The patch does work. Should we add this to README (btw, the documentation rocks) or would you like me to submit a PR? We have at least 5 users here on Yosemite that are either using/will start using pvaPy very shortly. I am doing my best to urge people to use it here since most are just building their beamlines. It is my goal to make all of them adopt v4 and python seems like the easiest path for their very first applications.

—
Reply to this email directly or view it on GitHub.

[sveseli]

Greg,

Patch is already in the repo. I still need to go over the README file to
make sure it reflects the most recent build state, but before I do that
I've got to look into Dave's pull request, which removes support for 4.3.0,
and hence changes some of the configuration stuff.

Sinisa

On Wed, Aug 12, 2015 at 1:08 PM, Greg White notifications@github.com
wrote:

Arman, Sinisa,

If you update the repo with the patch and Ernest’s discovered updates for
the README, I’ll
try a clean build for Yosemite following the instructions as given.

We’re about to have a number of physicists and operators use it, many on
Yosemite, so
I want to make sure it works out of the box.

Cheers
Greg

On Aug 12, 2015, at 9:57 AM, sveseli notifications@github.com wrote:

Hi Sinisa,

The patch does work. Should we add this to README (btw, the
documentation rocks) or would you like me to submit a PR? We have at least
5 users here on Yosemite that are either using/will start using pvaPy very
shortly. I am doing my best to urge people to use it here since most are
just building their beamlines. It is my goal to make all of them adopt v4
and python seems like the easiest path for their very first applications.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[ghost]

Commit 24511ad closes this issue