Comment 10 for bug 1553304

I am now calling epicsEnvSet("ARCH", targetArch) from the iocshRegisterCommon() routine in ioc/misc, but this is not a universal solution.

On VxWorks (and some RTEMS configurations) the startup script needs to know the architecture so it can load its .munch file from the right bin directory, and the iocshRegisterCommon() routine isn't executed until the .munch file is loaded (it's called from the C++ static constructor generated in the ioc_registerRecordDeviceDriver.cpp file). Thus for VxWorks IOCs the cdCommands file still needs to define topbin with the target-architecture included, so the iocBoot/ioc/Makefile must specify ARCH.

For Windows IOCs the user must have called/sourced the generated dllPath.bat or relPaths.sh (Cygwin) files before starting the IOC, thus the iocBoot/ioc/Makefile must have ARCH set to generate those files. We can't assume that the IOC architecture is the same as EPICS_HOST_ARCH, users may have cross-built for win32-x86-static for example.

The generated cdCommands and envPaths files no longer set ARCH though, and an iocBoot/ioc directory for a Unix-like OS can be architecture-independent. The makeBaseApp.pl script still needs the IOC architecture so it can expand the #! line which does contain _ARCH_, but the user could still run the IOC on a different architecture as long as they don't rely on the #! mechanism to find the IOC executable.

See the new branch lp:~epics-core/epics-base/ioc-arch for the current implementation.