Experimental Physics and Industrial Control System
We do have a minimum GCC version for C++ purposes which disqualifies
VxWorks 5.5 and some of the earlier VxWorks 6.x releases too. Here are
the relationships, from CONFIG.Common.vxWorksCommon
VX_GNU_VERSION_6.0 = 3.3.2
VX_GNU_VERSION_6.1 = 3.3.2
VX_GNU_VERSION_6.2 = 3.3.2
VX_GNU_VERSION_6.3 = 3.4.4
VX_GNU_VERSION_6.4 = 3.4.4
VX_GNU_VERSION_6.5 = 3.4.4
VX_GNU_VERSION_6.6 = 4.1.2
VX_GNU_VERSION_6.7 = 4.1.2
VX_GNU_VERSION_6.8 = 4.1.2
VX_GNU_VERSION_6.9 = 4.3.3
Since my VxWorks 6.8 builds are still working I assume that minimum GCC
version is around 4.1.2, so the earliest VxWorks I would expect to build
would be 6.6.
The taskWait() routine was added in one of the VxWorks 6.9 versions but
apparently sometime after 6.9.0; in my taskLib.h the modification
history has:
08q,14jun11,jpb Added waitPendQ to WIND_TCB, taskWait() declaration.
(Req: WIND00070880).
There's a version check in our header
modules/libcom/src/osi/os/vxWorks/osdThread.h which can be adjusted to
not need that. You will need to add _WRS_VXWORKS_MAINT to the check
which holds the next version component after _MINOR. If you can't find
out exactly when use 6.9.4 or 6.9.4.1, so maybe change the header
contents to this:
#include <epicsVersion.h>
#ifdef _WRS_VXWORKS_MAJOR
#define VXWORKS_VERSION_INT VERSION_INT(_WRS_VXWORKS_MAJOR, \
_WRS_VXWORKS_MINOR, _WRS_VXWORKS_MAINT, _WRS_VXWORKS_SVCPK)
#else
/* Version not available at compile-time, assume... */
#define VXWORKS_VERSION_INT VERSION_INT(5, 5, 0, 0)
#endif
#if VXWORKS_VERSION_INT < VERSION_INT(6, 9, 4, 1)
# undef EPICS_THREAD_CAN_JOIN
#endif
A warning about installing Wind River's cumulative patches to bring your 6.9.0 installation up to 6.9.4 or later: They do change the ABI, so would require you to rebuild your applications code; it was something to do with networking, I think one of the socket information structures got extended. This update hit our beamlines, and because it was the 3rd component it needed some local modifications to the build system to get around.
Another note: The current plan of the APS Controls group is to switch
our slowly declining number of VME systems to run RTEMS-5.x and not try
to support VxWorks 7.x here at all, although we do have a license for
it. Thus as long as that development effort works out I will not be
porting EPICS to VxWorks 7.
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1913699
Title:
vxWorks compilation fails with undeclared function
Status in EPICS Base:
New
Bug description:
Since -Werror-implicit-function-declaration has been added to configure/CONFIG.gnuCommon in commit b49f0691, EPICS base 7.0 compilation fails for vxWorks in:
../osi/os/vxWorks/osdFindSymbol.c: In function `epicsLoadLibrary':
../osi/os/vxWorks/osdFindSymbol.c:49: error: implicit declaration of function `close'
VxWorks declares close() in ioLib.h.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1913699/+subscriptions
- References:
- [Bug 1913699] [NEW] vxWorks compilation fails with undeclared function Dirk Zimoch via Core-talk
- Navigate by Date:
- Prev:
Re: RT linux and priorities Michael Davidsaver via Core-talk
- Next:
Re: iocsh scripts and not using $PWD Ben Franksen via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
2025
- Navigate by Thread:
- Prev:
[Bug 1913699] Re: vxWorks compilation fails with undeclared function Dirk Zimoch via Core-talk
- Next:
[Bug 1913699] Re: vxWorks compilation fails with undeclared function Dirk Zimoch via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
2025