EPICS Controls 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  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS build system DESTDIR support
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Wed, 5 Oct 2016 14:48:50 -0500
Hi Lewis,

On 10/05/2016 12:53 PM, J. Lewis Muir wrote:
> What would it take to get DESTDIR support added to the EPICS build
> system?  I haven't looked, but I would think doing it for Linux and
> macOS would not be too hard, but I don't know about Windows or other
> platforms.  And then there's cross-compiling, which is probably tricky,
> and for which I'd be interested in VxWorks.
> 
> There was a thread about this two years ago at [1].

> [1] http://www.aps.anl.gov/epics/tech-talk/2014/msg01500.php

The main complication with doing something like this is that the act of
building Base involves running programs that were compiled earlier in
the same build. Those programs need to be able to find shared libraries
that have also only just been built, and the way we implemented that on
Unix-like systems was to use the linker's RPATH.

We added the LINKER_USE_RPATH=NO support for Michael to use with the
Debian packages, but as he mentioned in the above thread, doing that
requires you to set LD_LIBRARY_PATH or use the /etc/ld.so.conf mechanism
to set the shared library search path at both build-time and run-time.
Editing the RPATH in existing binaries doesn't seem to be well
supported, and isn't an approach I would be keen on.

Michael's message in the above thread said:
> $ make FINAL_LOCATION=/usr/local/epics INSTALL_LOCATION=/tmp/builddir LINKER_USE_RPATH=NO
> 
> The LINKER_USE_RPATH=NO is necessary as rpath is always set using INSTALL_LOCATION.

It occurs to me that we might be able to set RPATH using FINAL_LOCATION
instead of INSTALL_LOCATION if the GNUmake build scripts were to set
LD_LIBRARY_PATH for the build-time search resolution. I don't know if
this would help in solving your problem, it might.

Note that on Windows there is no equivalent to RPATH, so there the
GNUmake build scripts just add the INSTALL_BIN directory to PATH (DLLs
are installed into the bin directory, not lib). Users have to manage
their own PATH when building and running IOCs and client programs,
although we do generate a script for IOCs to set PATH based on the IOC's
RELEASE file.

Before she retired Janet Anderson was working on an alternative approach
for Unix-like systems using $ORIGIN in the RPATH, but that wasn't
working out very well when you have multiple modules installed in
different locations. $ORIGIN lets you embed a search path for shared
libraries that is relative to the current location of the binary executable.

One other related thing that I've been doing has been to convert those
programs that have to run at build time into Perl scripts. Some of them
have been replaced in the Base-3.16 branch, but there are still some
major ones that I don't intend to tackle myself — flex and antelope
being the main ones (think Lex and Yacc/Bison). They generate C code to
run in the IOC for parsing database and access security files, and I
have never seen a Perl version of either of them that can output C or
C++ code.

If you or someone else wants to develop an alternative way to handle
these build issues the core developers would be happy to advise and
help, but any replacement must support builds on Linux, Windows and
macOS/darwin at minimum, and handle cross-builds for the majority of our
current cross-targets.

> If it's feasible, is this something that could go in 3.14, 3.15, or
> 3.16?  (Or maybe it already exists in newer branches?)  My thinking
> is that it could go into any of those branches by making it backward
> compatible by making it an option that is disabled by default.

Minor build system changes can be implemented on older branches provided
they are backwards-compatible — for example I just added cross-build
support for the windows-x64-mingw target from Linux to the Base-3.14
branch for the up-coming 3.14.12.6 release. However anything that
requires modifications to existing application Makefiles will probably
have to go into the developer branch, currently Base-3.16.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Replies:
Re: EPICS build system DESTDIR support Michael Davidsaver
References:
EPICS build system DESTDIR support J. Lewis Muir

Navigate by Date:
Prev: EPICS build system DESTDIR support J. Lewis Muir
Next: Re: ioc executable being made corrupted Torsten Bögershausen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS build system DESTDIR support J. Lewis Muir
Next: Re: EPICS build system DESTDIR support Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 07 Oct 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·