Experimental Physics and
Industrial Control System

"Gary V. Vaughan" <[email protected]> · Thu, 5 Aug 2010 20:18:25 +0000

Thanks for the fast responses,

I should clarify that I'm building on various releases of Solaris,
AIX, HPUX, IRIX and Tru64 (aka OSF/1) - because these are the
architectures my clients need native package installations for.

On Thu, Aug 05, 2010 at 03:50:00PM -0400, David Dudley wrote:
> Andrew,
> 
> Sorry for the discouraging remark, but setting "INSTALL_LOCATION" didn't
> work for me, when I built things for Darwin.

I have the same problem.

My choices seem to be either building as root in the install tree, and
then deleting the sources, or else relinking at install-time while I
copy the libraries and binaries into their final location in order
to make sure the RPATHs are set correctly.

> In order to successfully complete the build, I had to create symlinks to the
> installed location for the 'bin', 'configure', and 'include' directories.

I hadn't tried that option, though it sounds like it should work too.

> On 8/5/10 3:06 PM, "Andrew Johnson" <[email protected]> wrote:
> > On Thursday 05 August 2010 13:14:04 Gary V. Vaughan wrote:
> >> 
> >> I am in the process of trying to package EPICS base 3.14.11 into
> >> native package format on several commercial UNICES, but I can't
> >> find a nice way to have it install into a standard tree:
> > 
> > The EPICS build system isn't going to work with the standard tree that you've
> > suggested.  EPICS was designed around the ability to cross-compile for other
> > architectures, which is why we install binaries and libraries into an
> > architecture-specific subdirectory of <top>/bin and <top>/lib respectively.
> > How/where are you going to store the EPICS Base libraries cross-compiled for
> > an RTEMS or vxWorks target?  The majority of EPICS sites need to do cross-
> > builds like that, and your solution is likely to be less interesting to them
> > if you prevent that by changing the installation structure.

Really, I'm just trying to avoid putting all the sources into
a runtime package, and to facilitate installing the final package
into it's own subtree, say /usr/packages/EPICS-3.14.11/, where the
/usr/package/EPICS-3.14.11/bin might be usefully added to a users
PATH to use epics base.  And where linking with the development
libraries can be done by adding -I/usr/package/EPICS-3.14.11/include
and -L/usr/packages/EPICS-3.14.11/lib to match the use of the many
other packages we produce.

The details of the directories underneath /usr/packages/EPICS-3.14.11/
won't spoil that scheme overly much.

Is it because of the bespoke build system that cross builds require
the configure tree and sources?  I'm only familiar with the way
GNU does cross compilation, and while it too requires a cross compile
environment with binaries and libraries for the target machine,
there's no need to move the host environment into subdirectories for
that to work.

Really, I'm mostly interested in getting the python epicsca APIs
working for which EPICS base is a prerequisite.  In that case I
think it's okay to ignore cross compilation issues I think?  If
not, what directories do I need to have in the EPICS base install
tree for epicsca to be useful?

> >> If I change INSTALL_LOCATION to be anything other than $(TOP)
> >> then make fails to find any sources to link, and there don't
> >> appear to be any installation rules to relink the libraries
> >> and binaries at install time -- nearly all other programs I've
> >> packaged provide a 'make install' rule for this purpose.
> > 
> >> Is there a way to install a runtime EPICS base into the root
> >> directory using the existing build system?
> > 
> > You should be able to set INSTALL_LOCATION inside the configure/CONFIG_SITE
> > file before you build base, pointing it to the top directory where you want it
> > to make the install tree.  This will ensure that the RPATH entries point to
> > the installation tree.  I'm guessing that it might not be possible to set it
> > to "/" if that's something that you're having problems with, although I'm not
> > sure why it would break.  Note that this also causes the configure directory
> > to be copied to $(INSTALL_LOCATION); it's needed by application developers to
> > build IOCs against this installation of Base.

That makes sense, and I'm happy to put a copy of the configure
tree in the install package. Although I suppose I'll also
need to mangle some of the directory settings in the CONFIG
files to make sure they will work with the install tree directory
locations rather than the (not packaged) bulid tree?

> > If you want to remove the RPATH entries you're probably better off editing the
> > configure/os/CONFIG files to remove the options, although you may find you
> > have to set /etc/ld.so.conf so our build tools like flex and antelope are able
> > to run.  I believe we've added an option to future releases to allow RPATH to
> > be turned off centrally.

On the contrary, RPATH entries are essential to the way our
packages are installed each to their own directory, otherwise
each user would have to maintain an insanely long LD_LIBRARY_PATH.
However, RPATHs pointing back to the build tree are not good,
which is why I took to the hack of installing each library and
binary in order and relinking it against the installed dependencies
with appropriate install tree RPATH settings (as opposed to
build tree RPATH settings).

Cheers,
-- 
Gary V. Vaughan ([email protected])

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System