On 05.10.2016 21:48, Andrew Johnson wrote:
> 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.
We are using this approach since quite some time for our IOC
applications. Our solution to the problem you mention above
("...multiple modules installed in different locations...") is perhaps
crude but works well in practice: the final application pulls in copies
of the shared libraries of all used modules (placing them under
INSTALL_BIN), and sets the RPATH to $ORIGIN, as in:
TOP=..
include $(TOP)/configure/CONFIG
#----------------------------------------
# ADD MACRO DEFINITIONS AFTER THIS LINE
MODULE_PATHS = $(SHRLIB_SEARCH_DIRS)
MODULE_LIBNAMES = $(notdir $(foreach dir,$(MODULE_PATHS),$(wildcard
$(dir)/lib*.a)))
MODULE_NAMES = $(MODULE_LIBNAMES:$(LIB_PREFIX)%.a=%)
## Linux
MODULES_Linux = $(foreach dir,$(SHRLIB_SEARCH_DIRS),$(wildcard
$(dir)/lib*.so*))
BIN_INSTALLS_Linux = $(MODULES_Linux)
LINKER_USE_RPATH=NO
USR_LDFLAGS += '-Wl,-rpath,$ORIGIN'
PROD_Linux += ...
include $(TOP)/configure/RULES
#----------------------------------------
# ADD RULES AFTER THIS LINE
(In fact, since our build machine runs Debian 7 which, unfortunately,
has a broken linker that does not properly handle $ORIGIN, the above
doesn't work for us, so instead what we actually do is
USR_LDFLAGS += '-Wl,-rpath,../../bin/$(T_A)'
which relies on the IOC being started from inside the location of its
startup script...)
One might think that copying all the shared libraries is inefficient. It
turns out that the overhead of the EPICS build system with its recursive
make invocations, plus execution of our own build rules which heavily
depend on perl and python scripts to generate db files and other stuff,
completely dwarfs the mere copying of a few megabytes.
One advantage of doing it this way is that we never rely on distributing
build results for support modules: only the final application that
builds the IOCs distributes stuff (to the host that runs the IOC). This
means that dependencies (except for system libraries) are fully handled
on the build machine.
Furthermore, our method of distribution is such that unchanged files
will not be transferred but merely hard-linked to an existing version on
the target side, so the pulled-in .so files will only rarely be moved
over the network at all (in fact only once when the application switches
to a new version of the module) and take up almost no extra space. In
fact, we have chosen this method in part because it greatly speeds up
distribution.
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
Attachment:
signature.asc
Description: OpenPGP digital signature
- Replies:
- Re: EPICS build system DESTDIR support Andrew Johnson
- Navigate by Date:
- Prev:
Re: Debian packages for debian 9 (stretch) ? Michael Davidsaver
- Next:
cross-gcc for vxWorks 5.4.2 on linux Dunning, Michael
- 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>
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS build system DESTDIR support Matt Newville
- Next:
Re: EPICS build system DESTDIR support Andrew Johnson
- 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>
2018
2019
2020
2021
2022
2023
2024
|