>> I'm slightly surprised that the VxWorks builds that I know synapps is
>> tested on didn't discover this issue.
We don't build streamDevice's IOC application for synApps, because I didn't want to modify that application to build with the sequencer, because it doesn't use the sequencer. Context: I'm grateful that Dirk allowed us to package streamDevice with synApps, and I don't want to rock that boat over something we don't use.
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
________________________________________
From: [email protected] [[email protected]] on behalf of Andrew Johnson [[email protected]]
Sent: Friday, October 07, 2016 10:30 AM
To: [email protected]
Subject: Re: StreamDevice fails to compile for RTEMS targets.
Hi Mike,
On 10/07/2016 08:04 AM, Michael Westfall wrote:
> What were able to finally figure out is that -- for RTEMS targets,
> anyway -- The order of PROD_LIBS += xxx matters. For example, to
> resolve the errors above, I moved the line PROD_LIBS += seq pv to
> below the lines that included the CALC and SSCAN libraries.
I'm slightly surprised that the VxWorks builds that I know synapps is
tested on didn't discover this issue.
> It must be that there is something different about how the linker in the
> RTEMS toolchain works that isn't a problem in the linker for Linux.
Actually the Linux linker would see exactly the same problem if the
build were configured to link with the static libraries instead of the
shared ones, but very few people build static executables on Linux
nowadays. Builds for VxWorks and RTEMS that generate loadable binaries
are normally linked statically since those OSs don't support shared
libraries.
Static linking normally happens in a single pass, so the linker goes
through each library in turn, searching for symbols that are needed and
adding any object files from that library that contain undefined symbols
to the output file. If a library added later turns out to need a file
from an earlier library that wasn't known to be needed when that library
was linked, the result is going to be an unresolved symbol and a build
failure.
If you're linking against shared libraries though, the final resolving
of undefined symbols doesn't happen until run-time, when all the object
files in each shared library get mapped into the executable anyway so
all library symbols then become available.
If you are using RTEMS with GeSYS then the situation is a bit more like
using shared libraries (or the old 3.13 VxWorks approach) because the
whole library gets loaded into memory. GeSYS has advantages as well as
disadvantages, but it does require more RAM in the target to hold the
symbol table. I don't believe synapps is currently set up to work with
GeSYS (but I may be wrong about that).
HTH,
- 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
- References:
- StreamDevice fails to compile for RTEMS targets. Michael Westfall
- RE: StreamDevice fails to compile for RTEMS targets. Mark Rivers
- RE: StreamDevice fails to compile for RTEMS targets. Mooney, Tim M.
- Fwd: StreamDevice fails to compile for RTEMS targets. Michael Westfall
- RE: StreamDevice fails to compile for RTEMS targets. Mooney, Tim M.
- Re: StreamDevice fails to compile for RTEMS targets. Michael Westfall
- Re: StreamDevice fails to compile for RTEMS targets. Andrew Johnson
- Navigate by Date:
- Prev:
hw-talk mailing list Jukka Pietarinen
- 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
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: StreamDevice fails to compile for RTEMS targets. Andrew Johnson
- Next:
NDDataType change Hinxx
- 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
|