Re: StreamDevice fails to compile for RTEMS targets.

[Michael Westfall <mwestfal@gemini.edu>]

OK, putting PROD_LIBS += sscan back into the Makefile does take care of undefined references in swait.c to functions is sscan, but now the errors are different:

/gem_sw/prod/R3.14.12.4/support/calc/3-6-1-2/lib/RTEMS-beatnik/libcalc.a(editSseq.o): In function `seqg_entry_editSseq_0_newCommand':
/gem_sw/prod/R3.14.12.4/support/calc/3-6-1-2/calcApp/src/O.RTEMS-beatnik/../editSseq.st:220: undefined reference to `seq_pvGetTmo'

...etc.

Again, it compiles fine for the Linux target, but fails for RTEMS targets.

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.

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.

Anyway, with this revelation that the order of library inclusion matters, we are able to proceed.

Thanks.

On Thu, Oct 6, 2016 at 6:01 PM, Mooney, Tim M. <mooney@aps.anl.gov> wrote:

Hi Mike,

Take a look at streamApp/Makefile.  The version on github has these lines:

# older calc versions require sscan

#PROD_LIBS += sscan

It's complicated, because calc will build with or without sscan.  (Older calc versions could not build without sscan.)  If calc is built with sscan, anything that uses calc must link against sscan.

If your copy of stream has "PROD_LIBS += sscan" commented out, uncomment that line.

--

Mike Westfall

Control Systems Software Engineer